From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0395.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0395.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0395.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0395.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0395.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0395.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0395.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0395.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0395.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0395.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0395.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0395.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0395.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0395.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0395.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0395.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0395.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0395.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0395.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0395.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0395.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0395.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0395.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0395.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0395.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0395.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0396.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0396.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0396.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0396.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0396.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0396.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0396.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0396.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0396.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0396.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0396.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0396.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0396.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0396.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0396.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0396.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0396.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0396.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0396.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0396.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0396.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0396.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0396.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0396.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0396.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0396.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0397.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0397.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0397.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0397.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0397.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0397.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0397.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0397.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0397.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0397.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0397.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0397.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0397.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0397.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0397.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0397.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0397.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0397.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0397.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0397.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0397.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0397.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0397.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0397.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0397.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0397.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0398.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0398.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0398.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0398.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0398.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0398.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0398.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0398.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0398.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0398.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0398.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0398.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0398.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0398.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0398.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0398.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0398.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0398.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0398.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0398.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0398.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0398.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0398.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0398.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0398.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0398.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0399.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0399.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0399.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0399.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0399.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0399.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0399.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0399.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0399.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0399.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0399.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0399.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0399.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0399.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0399.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0399.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0399.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0399.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0399.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0399.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0399.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0399.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0399.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0399.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0399.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0399.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0400.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0400.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0400.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0400.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0400.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0400.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0400.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0400.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0400.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0400.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0400.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0400.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0400.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0400.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0400.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0400.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0400.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0400.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0400.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0400.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0400.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0400.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0400.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0400.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0400.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0400.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0401.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0401.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0401.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0401.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0401.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0401.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0401.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0401.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0401.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0401.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0401.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0401.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0401.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0401.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0401.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0401.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0401.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0401.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0401.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0401.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0401.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0401.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0401.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0401.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0401.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0401.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0402.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0402.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0402.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0402.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0402.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0402.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0402.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0402.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0402.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0402.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0402.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0402.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0402.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0402.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0402.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0402.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0402.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0402.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0402.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0402.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0402.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0402.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0402.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0402.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0402.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0402.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0403.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0403.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0403.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0403.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0403.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0403.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0403.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0403.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0403.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0403.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0403.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0403.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0403.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0403.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0403.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0403.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0403.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0403.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0403.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0403.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0403.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0403.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0403.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0403.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0403.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0403.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0404.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0404.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0404.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0404.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0404.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0404.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0404.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0404.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0404.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0404.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0404.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0404.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0404.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0404.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0404.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0404.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0404.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0404.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0404.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0404.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0404.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0404.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0404.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0404.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0404.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0404.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0001.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0001.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0001.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0001.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0001.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0001.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0001.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0001.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0001.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0001.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0001.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0001.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0001.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0001.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0001.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0001.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0002.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0001.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0001.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0001.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0001.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0001.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0001.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0002.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0002.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0002.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0002.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0002.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0002.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0002.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0002.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0002.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0002.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0002.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0002.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0002.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0002.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0002.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0003.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0002.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0002.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0002.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0002.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0002.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0002.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0003.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0003.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0003.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0003.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0003.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0003.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0003.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0003.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0003.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0003.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0003.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0003.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0003.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0003.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0003.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0004.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0003.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0003.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0003.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0003.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0003.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0003.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0004.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0004.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0004.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0004.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0004.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0004.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0004.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0004.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL From lyon at docjava.com Sun Jan 15 08:00:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 10:00:34 -0500 Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Trent, Does it make any sense to tweak the bootclasspath by adding URL's that reference the proper native jar files? I think I can put the sun.boot.class.path property, but this seems like such a hack (and I am not sure if it will work). There has got to be a cleaner way to do this...any ideas? Thanks! - Doug >>As you can see, if we can't write to the directory where the native >>methods go, it is a bit of a show stopper. Under windows, we >>would need Administrator passwords to do the install. Under Unix >>or Mac, we might need the root pwd. But even with these PWDS, >>I don't know how to override the lack of write permission to the >>directory. > > >On Solaris, Linux, FreeBSD and Mac OSX I know that for password >authentification, you need to 'PAM-ify' the library. That would >mean linking in the PAM libraries. I've not seen how this is done, >but CUPs should be an example program that does it. > >http://www.kernel.org/pub/linux/libs/pam/ > >This may even be in Java already as Solaris uses PAM. > >-- >Trent Jarvi >tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:40:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:40:18 -0700 (MST) Subject: [Rxtx] close() performance fix In-Reply-To: <1136300234.27620.35.camel@localhost.localdomain> References: <1136300234.27620.35.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > > Improved performance of close(). Shaved off 200ms'ish on a Linux Debian > box. ?yvind Harboe > Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. > ?yvind Harboe > > The gc() calls are now removed in cvs. I'm going through the list and putting several changes in one at a time. I'll post a summary in a bit. The changes are only in rxtx 2.1 cvs so far. There needs to be a cleanup of a mistake in the 2.0 cvs before they all come back. ( Basically the code was autoformated making it hard to see the differences. Plus it turns out the code reveal many issues with the autoformating tool I didnt notice at first ) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 19:57:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 19:57:29 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: <9566540734.20051230122957@domologic.de> References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: On Fri, 30 Dec 2005, Gerrit Telkamp wrote: > As proposed by Trent, I will describe my patches here: > > 1- The main patch was in termios.c line 1188, where a close-Method is > called when an error occured (cause by check_port_capabilities). It is > wrong to call close() here, because termios.c used CreateFile to open > the port (in the function open_port). Therefore, "serial_close" has to > be called, updating the internal port management structure. > > I think the origin is that in a previous release of RXTX this function > has been named "close()", later renamed to "serial_close()". In > several debug outputs you also find "close" instead of "serial_close" > and "open" instead of "serial_open" (Lines > 606,615,632,668,863,1170,1178). I would also propose to update these > debug outputs, because it confused me while reading the code. > > 2- in "Serial.def", Line 4, the export declaration of > "nativeGetVersion" is wrong (the JNI method declaration > is done in RXTXVersion.java, not in RXTXCommDriver.java) > Line 4 Replaced by > Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 > > 3- in "Configure.java", Line 160: > Wrong message, because the name of the properties file is > "gnu.io.rxtx.properties" (not "gnu.io.comm.properties") > The message could cause some confusion. > > 4- In my environment, I get an error message because the JNI functions > JNI_OnLoad and JNI_OnUnload are declared twice: in init.c and in > SerialImp.c. > The declaration in init.c is not used anymore, so I propose to > comment it out. > These are in cvs now except for the Serial.def which will be automatically generated when we start building the windows libraries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 15 20:20:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 20:20:27 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 15 Message-ID: I'll Still be going through the list and making sure I've not missed anything. This will probably be it for tonight though. If you know I missed something or have other things you would like to see in, let me know. Also note, that none of the autogenerated files have been created yet. Thats just CVS noise at this point. Each change was made in a seperate commit if you wish to review the patches. This is all in rxtx 2.1 CVS. 2.0 will get them when we finish. http://www.rxtx.org/cvs.html if you need help on using the CVS. 2.1-8 Jan ?? 2006 Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction Use serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html From tjarvi at qbang.org Sun Jan 15 21:11:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:11:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Hi Doug I've been watching you trying to figure out what the best way to do this is. I looked a little yesterday concerning your idea of a function that asked for passwords and wrote what needed to be wrote. I suggested that on Unix like systems people use Password Authentification Modules (PAM). I see jdk1.5 has a JAAS package included now which does PAM on all the major OS's including w32. I couldnt see using 'ldd' and 'nm' that the native PAM libraries are called. I have questions about how much it can do. With the downloadable JAAS (http://java.sun.com/products/jaas/) package they do have an example in the source that gives read permission. I was going to look further but I could not get the example to work. Perhaps it is all withing the Java sandbox and it wont do what you need. I ran out of time. It looks interesting. With the read example, it would be fairly easy to see if it does what is needed. Just put the file in an higher permission directory that needs PAM to read. That may be a reasonable way of doing the install if the user understands what is being done, the install does not cause harm to other packages and the install is easily undone. On Sun, 15 Jan 2006, Dr. Douglas Lyon wrote: > Hi Trent, > Does it make any sense to tweak the bootclasspath > by adding URL's that reference the proper native jar files? > I think I can put the sun.boot.class.path property, but this seems like > such a hack (and I am not sure if it will work). > There has got to be a cleaner way to do this...any ideas? > Thanks! > - Doug > >>> As you can see, if we can't write to the directory where the native >>> methods go, it is a bit of a show stopper. Under windows, we >>> would need Administrator passwords to do the install. Under Unix >>> or Mac, we might need the root pwd. But even with these PWDS, >>> I don't know how to override the lack of write permission to the >>> directory. >> >> >> On Solaris, Linux, FreeBSD and Mac OSX I know that for password >> authentification, you need to 'PAM-ify' the library. That would mean >> linking in the PAM libraries. I've not seen how this is done, but CUPs >> should be an example program that does it. >> >> http://www.kernel.org/pub/linux/libs/pam/ >> >> This may even be in Java already as Solaris uses PAM. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > From tjarvi at qbang.org Sun Jan 15 21:36:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 21:36:51 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: If you would like to submit a SafeCommDriver.java file with the ideas included, we can put it in CVS. I don't see how its going to do harm. It looks like it just needs a couple stubs suggesting possible future work where you mentioned the questions. On Sat, 14 Jan 2006, Dr. Douglas Lyon wrote: > Quite right! > > To be thread safe, the > getInstance should be synchronized. > > Also, in order to beam the native libs into > the jdk/jre/lib/i386 directories, the user will need > to have write permission to the directory. > > How do you prompt the user for a root password so that > the installation can proceed? > > For example: > public static void checkDriver() { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > badCommDriver(); > else System.out.println("driver OK!"); > } > > private static void badCommDriver() { > if (!In.getBoolean("Could not load RXTX driver. \n" + > "Do you want me to install it?")) return; > fixDriver(); > checkDriver(); > } > > private static void fixDriver() { > installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), > "select a path for install", > "path selector dialog")); > } > > private static void installDriver(String path) { > if (path == null) > System.exit(0); > File f = new File(path); > if (!f.canWrite()) { > In.message("you can't write to:" + path); > fixDriver(); > } > In.message("you have selected:"+f.getAbsolutePath()); > In.message("not implemented yet"); > System.exit(0); > } > > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. > > Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html > Authorization toolkit. But what about others? > > Is there another way to do the native lib install? > > Thanks! > - Doug > > >> Hi, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because if >> you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other thread >> starts the same game... and now you have two instance... could give some >> problems?! >> >> >> -----Urspr?ngliche Nachricht----- >> Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >> Dr. Douglas Lyon >> Gesendet: Samstag, 14. Januar 2006 12:28 >> An: RXTX Developers and Users; lyon at docjava.com >> Betreff: [Rxtx] singleton design pattern >> >> Hi All, >> I see initialize being called more than once in static blocks >> contained by the RXTXCommDriver. >> >> However, it is my understanding that initialize should not >> be called more than once. >> >> More importantly, we need a run-time means to determine >> if a driver can be loaded. >> >> Would it be better design to make use of the Singleton Design Pattern >> to obtain an instance of the RXTXCommDriver? >> >> Something like: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public static CommDriver getInstance() { >> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> private static boolean isLoaded() { >> if (!NativeLibDetect.isLibInPath("rxtxSerial")) >> return false; >> System.loadLibrary("rxtxSerial"); >> return true; >> } >> >> public static void main(String[] args) { >> System.out.println("SafeCommDriver"); >> CommDriver cd = getInstance(); >> if (cd == null) >> System.out.println("program terminates; could not load >> RXTX driver"); >> else System.out.println("driver OK!"); >> } >> } >> Adding the SafeCommDriver to the CommDriver access should do no harm, >> and it would >> give a central point for checking the existence of the native library >> in the load path before throwing an exception. It also makes sure >> that initialize is invoked only once. Finally, if the >> library is missing, we could offer to install it...at run time, from >> a web page. This might make the serial port software more robust. >> >> - Doug >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 tjarvi at qbang.org Sun Jan 15 22:16:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > This will have to wait until I get a modem, but What I'd probably look at is an unused function in termios.c called FillDCB(). This function can be modified to your liking. Anyplace rxtx does a SetCommState(), just call FillDCB() instead or comment it out. Will FillDCB() you can set the entire windows structure to whatever you need. From there you can work out just what rxtx is doing wrong. You may be able to spot what is wrong after seeing the DCB structure and working back through the code. Let me know if you would like an account for building/timkering. After looking through the list, Through the archives, I suspect there is a problem on w32 Flow control related. -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Sun Jan 15 23:17:44 2006 From: tma at mail.island.net (Tom Alldread) Date: Sun, 15 Jan 2006 22:17:44 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43CB3A88.8030602@mail.island.net> Hi Trent: Great to hear! Many thanks for the info! Tom Trent Jarvi wrote: > On Fri, 13 Jan 2006, Tom Alldread wrote: > >> Greetings Folks: >> >> I am wondering if anyone here knows if Sun has any intention of >> providing CommApi 3 support for Windows platforms in the future? >> Seems like a huge arena for Sun to leave void of JAVA comm support. >> Makes me wonder if I missed something with my several attempts to >> find Windows comm support within Sun's JAVA web site. >> >> I apologize if this is a little out of context but I just don't know >> where else there is for a hobbyist to ask this question. >> > > Hi Tom > > Speaking for rxtx, we will be supporting windows in the next release > Sun makes of CommAPI 3.0. That is the plan over hear. We have > discussed current problems with 3.0 and it appears that those issues > will be addressed. > > I hope Sun also make a windows release giving users more options. You > would have to communicate with Sun to know what their plans are. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -- Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From x.frisaye at t4hr.com Mon Jan 16 00:45:19 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Mon, 16 Jan 2006 08:45:19 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi Trent, Thanks for your reply. No I haven't tried changing the default timeout yet, how can i do that? Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: samedi 14 janvier 2006 14:28 To: RXTX Developers and Users Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jsmsengine at gmail.com Mon Jan 16 01:12:50 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Mon, 16 Jan 2006 10:12:50 +0200 Subject: [Rxtx] Win32 problems. Message-ID: <4f8cec620601160012o3dd7b85bi40e7ba2bc630d92b@mail.gmail.com> > > > Message: 3 > Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > I cant see whats wrong right off. The code is going to write( int b ) in > RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() > calls serial_write() in termios.c. > > So the code isnt that hard to follow if you want to take a look. If you > have some ideas you want to try or debugging messages put it, I can give > you a working buildtree on qbang so you don't have to go through the mess > of setting that up. > > Which version of rxtx 2.1 did you try on windows? pre17 was tested a > great deal on windows but not with a modem. the snapshot was less tested. > > I may have to put together a machine with a modem.. > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > Hi Trend, its my feeling that the "bug" is somewhere in the receive methods. Here is why: I run my test with RxTx and I get nothing back, as described. Then, I run my test with Sun JavaComm, and on the first run I get duplicate responses. It seems that the previous test with RxTx has sent the commands, the modem responded but RxTx never managed to process that response. So next time, I get both responses back. I hope I've described it well... I would gradly help you locate the problem. When you find time, prepare that buildtree, or send a zip directly to me. Also tell me which compiler should I use. ( Times may force us all to move into more integrated RAD environments, but C is an ever-lasting passion! :) ) Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/688719e8/attachment-0004.html From tjarvi at qbang.org Mon Jan 16 09:07:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 09:07:22 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: 'SerialPort'.enableReceiveTimeout(int TimeInMS) A value of 100 or more should do it. Less than 100 is too small for Unix systems (which w32 is treated like in rxtx). So rxtx has decisecond resolution for timeouts on all platforms as specified by POSIX termios. On Mon, 16 Jan 2006, Xavier Frisaye wrote: > Hi Trent, > > Thanks for your reply. > No I haven't tried changing the default timeout yet, how can i do that? > > Regards, > > Xavier > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of > Trent Jarvi > Sent: samedi 14 janvier 2006 14:28 > To: RXTX Developers and Users > Subject: RE: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > > > On Fri, 13 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> We using rxtx in our application to send/receive sms (thus this is >> similar to jSMSEngine) and we're encountering one problem on windows >> 2000 server or XP based system. Our application is installed as a NT >> Service using JavaService.exe and when the server reboots, the >> application is listening for ever to the port. But if we restart the >> service, the application works. Sometimes, it also happens while the >> application is running for a long time. When using Sun's Comm api 2.0 >> for Win32 the first problem seems to be solved (We haven't test the >> second problem with Sun's Comm and thus i can't affirm it doesn't occurs >> in this case). I think our problems are very similar to yours but we >> don't have found any solutions yet. >> >> Regards, >> >> Xavier Frisaye >> > > Hi Xavier > > listening for ever... Have you tried changing the default timeout? I > suspect Sun and RXTX just have different defaults (never timeout in the > RXTX case). > > -- > 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 paul.klissner at sun.com Mon Jan 16 12:18:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 11:18:47 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CB3A88.8030602@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> Message-ID: <43CBF197.6010001@sun.com> Tom Alldread wrote: > Hi Trent: > > Great to hear! > > Many thanks for the info! > > Tom > > > Trent Jarvi wrote: > >> On Fri, 13 Jan 2006, Tom Alldread wrote: >> >>> Greetings Folks: >>> >>> I am wondering if anyone here knows if Sun has any intention of >>> providing CommApi 3 support for Windows platforms in the future? >>> Seems like a huge arena for Sun to leave void of JAVA comm support. >>> Makes me wonder if I missed something with my several attempts to >>> find Windows comm support within Sun's JAVA web site. >>> >>> I apologize if this is a little out of context but I just don't know >>> where else there is for a hobbyist to ask this question. >>> >> >> Hi Tom >> >> Speaking for rxtx, we will be supporting windows in the next release >> Sun makes of CommAPI 3.0. That is the plan over hear. We have >> discussed current problems with 3.0 and it appears that those issues >> will be addressed. >> >> I hope Sun also make a windows release giving users more options. You >> would have to communicate with Sun to know what their plans are. Porting RxTx is not a in the plans right now. There just isn't the resource allocation to do it right. That could change, but it isn't on the RADAR right now. Paul From tjarvi at qbang.org Mon Jan 16 12:43:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 12:43:33 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43CBF197.6010001@sun.com> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Mon, 16 Jan 2006, Paul Klissner wrote: > Tom Alldread wrote: >> Hi Trent: >> >> Great to hear! >> >> Many thanks for the info! >> >> Tom >> >> >> Trent Jarvi wrote: >> >>> On Fri, 13 Jan 2006, Tom Alldread wrote: >>> >>>> Greetings Folks: >>>> >>>> I am wondering if anyone here knows if Sun has any intention of providing >>>> CommApi 3 support for Windows platforms in the future? Seems like a huge >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if I >>>> missed something with my several attempts to find Windows comm support >>>> within Sun's JAVA web site. >>>> >>>> I apologize if this is a little out of context but I just don't know >>>> where else there is for a hobbyist to ask this question. >>>> >>> >>> Hi Tom >>> >>> Speaking for rxtx, we will be supporting windows in the next release Sun >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed >>> current problems with 3.0 and it appears that those issues will be >>> addressed. >>> >>> I hope Sun also make a windows release giving users more options. You >>> would have to communicate with Sun to know what their plans are. > > Porting RxTx is not a in the plans right now. There just > isn't the resource allocation to do it right. That could > change, but it isn't on the RADAR right now. > Hi Paul I just want to make sure we understand each other because the above is a bit confusing. Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a w32 port Sun offered. Last I looked, this was not offered with CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 API calls hard coded into CommAPI that made no OS agnostic sense. I think the Sun w32 port of CommAPI 3.0 was what the original poster was asking... will there be one. The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX system with its own termios. The objection was that the recent CommAPI is not abstracting the native calls (and grumble.. some of the calls are beyond POSIX Unix specific targeting specific Sun products). So I thought it was agreed that the hard coded native calls which only allow rxtx to work on platforms Sun has time and resources to compile to would be abstracted as was done in CommAPI 2.0 with the javax.comm.properties concept. That way Sun does not really need to do more so long as hackers can tinker with rxtx and plug it in no matter what hardware or OS they choose. Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This is in package gnu.io to avoid confusion with Sun's work in Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which will work with Sun's CommAPI assuming the main design issues are resolved. People will have at least one way to use w32 on Sun CommAPI if what I thought we agreed to works out. One last note, you mentioned frustration with dealing with things like hotplug devices and so forth. RXTX can work along with those and we also have interest in other platforms so long as its possible to do it from this end. The complaint was we could not really offer anything the way the last release was designed. -- Trent Jarvi tjarvi at qbang.org From neil.benn at gmail.com Mon Jan 16 16:06:15 2006 From: neil.benn at gmail.com (Neil Benn) Date: Tue, 17 Jan 2006 00:06:15 +0100 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hello, I would just like to give my fourpenneth, I am currently working in the industry of Biopharmaceutical R&D, I use Java to control equipment for this industry. The majority of equipment is controlled with RS232 communication and Java has a small inroad into this (equipment to enterprise communication) multi-billion dollar a year industry. I've worked as a pioneer of the utilisation of java for this task in the last 7 years (the majority of apps in this area use VB, 'hacky' python/perl/ruby scripts {although these can be non-hacky} or over complicated C++ - however .NET is also starting to make inroads with VB.NET due to the EOL of VB6). I'm currently using WinXP and WinCE (distributed by NSICom) and writing applications on RS232 utilising javax.comm and have done this for GlaxoSmithkline, two other biotechs and my own company. Therefore this isn't really hobbyist stuff (not that there is anything wrong with that!) - to this end I use javax.comm 2.1 which works with windows and can happily continue with this however I'm am keenly watching RxTx as I appreciate the commitment shown by Trent and others. IMHO, the fact that C? is adding good RS232 and sun is removing it (regardless of a decent WinCE J2ME!) makes me worry - I like Java and want to keep using it - the new util.concurrency stuf helps me cut out my own code (I prefer to delete code than write it!). Yours, keenly observing, Neil On 1/16/06, Trent Jarvi wrote: > > On Mon, 16 Jan 2006, Paul Klissner wrote: > > > Tom Alldread wrote: > >> Hi Trent: > >> > >> Great to hear! > >> > >> Many thanks for the info! > >> > >> Tom > >> > >> > >> Trent Jarvi wrote: > >> > >>> On Fri, 13 Jan 2006, Tom Alldread wrote: > >>> > >>>> Greetings Folks: > >>>> > >>>> I am wondering if anyone here knows if Sun has any intention of > providing > >>>> CommApi 3 support for Windows platforms in the future? Seems like a > huge > >>>> arena for Sun to leave void of JAVA comm support. Makes me wonder if > I > >>>> missed something with my several attempts to find Windows comm > support > >>>> within Sun's JAVA web site. > >>>> > >>>> I apologize if this is a little out of context but I just don't know > >>>> where else there is for a hobbyist to ask this question. > >>>> > >>> > >>> Hi Tom > >>> > >>> Speaking for rxtx, we will be supporting windows in the next release > Sun > >>> makes of CommAPI 3.0. That is the plan over hear. We have discussed > >>> current problems with 3.0 and it appears that those issues will be > >>> addressed. > >>> > >>> I hope Sun also make a windows release giving users more options. You > >>> would have to communicate with Sun to know what their plans are. > > > > Porting RxTx is not a in the plans right now. There just > > isn't the resource allocation to do it right. That could > > change, but it isn't on the RADAR right now. > > > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was a > w32 port Sun offered. Last I looked, this was not offered with CommAPI > 3.0. This w32 was not very interesting to rxtx as it had w32 API calls > hard coded into CommAPI that made no OS agnostic sense. I think the Sun > w32 port of CommAPI 3.0 was what the original poster was asking... will > there be one. > > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI is > not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter what > hardware or OS they choose. > > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. This > is in package gnu.io to avoid confusion with Sun's work in Javax.comm. > The 2.1 code will easily be backported into rxtx 2.0 which will work with > Sun's CommAPI assuming the main design issues are resolved. People will > have at least one way to use w32 on Sun CommAPI if what I thought we > agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we also > have interest in other platforms so long as its possible to do it from > this end. The complaint was we could not really offer anything the way > the last release was designed. > > -- > 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: http://mailman.qbang.org/pipermail/rxtx/attachments/20060116/e564a97a/attachment-0004.html From tjarvi at qbang.org Mon Jan 16 16:59:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 16:59:47 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: > IMHO, the fact that C? is adding good RS232 and sun is removing > it (regardless of a decent WinCE J2ME!) Michal Hobot contributed a WinCE port to RXTX if you are interested. It is in the WinCE directory with the rxtx source code. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Mon Jan 16 17:50:35 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 16 Jan 2006 16:50:35 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <43CC3F5B.3010107@sun.com> Trent Jarvi wrote: >>>> Hi Tom >>>> I hope Sun also make a windows release giving users more options. >>>> You would have to communicate with Sun to know what their plans are. >> >> Porting RxTx is not a in the plans right now. There just >> isn't the resource allocation to do it right. That could >> change, but it isn't on the RADAR right now. >> > > Hi Paul > > I just want to make sure we understand each other because the above is a > bit confusing. > > Perhaps you mean porting Sun CommAPI to w32? With CommAPI 2.0 there was > a w32 port Sun offered. Last I looked, this was not offered with > CommAPI 3.0. This w32 was not very interesting to rxtx as it had w32 > API calls hard coded into CommAPI that made no OS agnostic sense. I > think the Sun w32 port of CommAPI 3.0 was what the original poster was > asking... will there be one. I pulled Sun's Win32 2.0 port from the SDLC because I don't want to ship buggy code that is literally several years out of date, which hasn't been built or even looked at by our company for that long, particularly with other offerings currently available. > The Solaris port did make sense to rxtx since rxtx treats w32 as a POSIX > system with its own termios. The objection was that the recent CommAPI > is not abstracting the native calls (and grumble.. some of the calls are > beyond POSIX Unix specific targeting specific Sun products). Right, and that is because it didn't occur to me that anyone except Sun laid claim to javax.comm's binary interfaces. I believed the API represented the stability contract with the public. While the driver property provides a clue, one could not easily infer it's public use. In the abscence of a documented SPI, why would anyone assume an external entity knew or *should* know much about the backside interfaces? Had I been more familiar with RxTx, I'd have known better. Just for the record, the reason I added extra interfaces to 3.0 JNI, which RxTx finds problematic, was to avoid adding an extra library to the distribution. Not the end of the world, but I preferred to avoid complicating things for Sun's end users. Adding a new native library to the distribution now seems unavoidable, to incorporate new platform bindings to support our Sun Ray thin client. > > So I thought it was agreed that the hard coded native calls which only > allow rxtx to work on platforms Sun has time and resources to compile to > would be abstracted as was done in CommAPI 2.0 with the > javax.comm.properties concept. That way Sun does not really need to do > more so long as hackers can tinker with rxtx and plug it in no matter > what hardware or OS they choose. That's what I've agreed to do. > Rxtx will be putting resources into the seperate rxtx 2.1 w32 port. > This is in package gnu.io to avoid confusion with Sun's work in > Javax.comm. The 2.1 code will easily be backported into rxtx 2.0 which > will work with Sun's CommAPI assuming the main design issues are > resolved. People will have at least one way to use w32 on Sun CommAPI > if what I thought we agreed to works out. > > One last note, you mentioned frustration with dealing with things like > hotplug devices and so forth. RXTX can work along with those and we > also have interest in other platforms so long as its possible to do it > from this end. The complaint was we could not really offer anything the > way the last release was designed. Ideally a JSR will be opened to develop a better javax.comm SPI and resolve other issues (such as multi-JVM comm. port ownership management). A good example of an offering midwifed by the JCP is javax.usb (JSR-80): http://jcp.org/en/jsr/detail?id=80 javax.usb is available through SourceForge, so I know the JCP process works. I was Sun's rep on the E.G., yet Sun was not the spec. lead. It was a collaboration of diverse interests. javax.usb is a good example of how a Java API can seperate platform dependent vs. independent layers with better abstraction. javax.usb uses a triple tiered approach. There is the API layer, just interface classes, and a reference implemenation (optional middle layer) that can be utilized to simplify porting. The RI contains all the platform neutral java source code. By using the RI, porters need only implement the lowest layer (a thin layer of Java and JNI) for their platform. Native interfaces are *not* hardcoded into the RI middle layer, giving porters a lot of leeway as to how to organize their code. -Paul From tjarvi at qbang.org Mon Jan 16 19:22:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:22:49 -0700 (MST) Subject: [Rxtx] [patch 29/12] serial_close in termios.c In-Reply-To: References: <1135882126.18893.4.camel@localhost> <47047718.20051229195824@domologic.de> <9566540734.20051230122957@domologic.de> Message-ID: >> 2- in "Serial.def", Line 4, the export declaration of >> "nativeGetVersion" is wrong (the JNI method declaration >> is done in RXTXVersion.java, not in RXTXCommDriver.java) >> Line 4 Replaced by >> Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 The autogenerated fix for this is in rxtx 2.1 CVS now. There had to be a few more fixes to catch up with CVS. Index: Serial.def =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/Serial.def,v retrieving revision 1.1.2.17 diff -u -r1.1.2.17 Serial.def --- Serial.def 18 Jul 2003 02:20:26 -0000 1.1.2.17 +++ Serial.def 17 Jan 2006 01:57:52 -0000 @@ -1,14 +1,15 @@ EXPORTS -Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner=Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner at 12 Java_gnu_io_RXTXCommDriver_getDeviceDirectory=Java_gnu_io_RXTXCommDriver_getDeviceDirectory at 8 Java_gnu_io_RXTXCommDriver_isPortPrefixValid=Java_gnu_io_RXTXCommDriver_isPortPrefixValid at 12 -Java_gnu_io_RXTXCommDriver_nativeGetVersion=Java_gnu_io_RXTXCommDriver_nativeGetVersion at 8 Java_gnu_io_RXTXCommDriver_registerKnownPorts=Java_gnu_io_RXTXCommDriver_registerKnownPorts at 12 Java_gnu_io_RXTXCommDriver_testRead=Java_gnu_io_RXTXCommDriver_testRead at 16 +Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 +Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 +Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 +Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_eventLoop=Java_gnu_io_RXTXPort_eventLoop at 8 Java_gnu_io_RXTXPort_getInputBufferSize=Java_gnu_io_RXTXPort_getInputBufferSize at 8 Java_gnu_io_RXTXPort_getOutputBufferSize=Java_gnu_io_RXTXPort_getOutputBufferSize at 8 -Java_gnu_io_RXTXPort_Initialize=Java_gnu_io_RXTXPort_Initialize at 8 Java_gnu_io_RXTXPort_interruptEventLoop=Java_gnu_io_RXTXPort_interruptEventLoop at 8 Java_gnu_io_RXTXPort_isCD=Java_gnu_io_RXTXPort_isCD at 8 Java_gnu_io_RXTXPort_isCTS=Java_gnu_io_RXTXPort_isCTS at 8 @@ -16,18 +17,15 @@ Java_gnu_io_RXTXPort_isDTR=Java_gnu_io_RXTXPort_isDTR at 8 Java_gnu_io_RXTXPort_isRI=Java_gnu_io_RXTXPort_isRI at 8 Java_gnu_io_RXTXPort_isRTS=Java_gnu_io_RXTXPort_isRTS at 8 -Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 +Java_gnu_io_RXTXPort_nativeClearCommInput=Java_gnu_io_RXTXPort_nativeClearCommInput at 8 Java_gnu_io_RXTXPort_nativeClose=Java_gnu_io_RXTXPort_nativeClose at 12 Java_gnu_io_RXTXPort_nativeDrain=Java_gnu_io_RXTXPort_nativeDrain at 12 -Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold=Java_gnu_io_RXTXPort_NativeEnableReceiveTimeoutThreshold at 20 Java_gnu_io_RXTXPort_nativeGetBaudBase=Java_gnu_io_RXTXPort_nativeGetBaudBase at 8 Java_gnu_io_RXTXPort_nativeGetDivisor=Java_gnu_io_RXTXPort_nativeGetDivisor at 8 Java_gnu_io_RXTXPort_nativeGetEndOfInputChar=Java_gnu_io_RXTXPort_nativeGetEndOfInputChar at 8 Java_gnu_io_RXTXPort_nativeGetFlowControlMode=Java_gnu_io_RXTXPort_nativeGetFlowControlMode at 12 Java_gnu_io_RXTXPort_nativeGetParity=Java_gnu_io_RXTXPort_nativeGetParity at 12 Java_gnu_io_RXTXPort_nativeGetParityErrorChar=Java_gnu_io_RXTXPort_nativeGetParityErrorChar at 8 -Java_gnu_io_RXTXPort_NativegetReceiveTimeout=Java_gnu_io_RXTXPort_NativegetReceiveTimeout at 8 -Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled=Java_gnu_io_RXTXPort_NativeisReceiveTimeoutEnabled at 8 Java_gnu_io_RXTXPort_nativeSetBaudBase=Java_gnu_io_RXTXPort_nativeSetBaudBase at 12 Java_gnu_io_RXTXPort_nativeSetDivisor=Java_gnu_io_RXTXPort_nativeSetDivisor at 12 Java_gnu_io_RXTXPort_nativeSetEndOfInputChar=Java_gnu_io_RXTXPort_nativeSetEndOfInputChar at 12 @@ -48,15 +46,18 @@ Java_gnu_io_RXTXPort_nativeStaticSetDTR=Java_gnu_io_RXTXPort_nativeStaticSetDTR at 16 Java_gnu_io_RXTXPort_nativeStaticSetRTS=Java_gnu_io_RXTXPort_nativeStaticSetRTS at 16 Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams=Java_gnu_io_RXTXPort_nativeStaticSetSerialPortParams at 28 +Java_gnu_io_RXTXPort_nativeavailable=Java_gnu_io_RXTXPort_nativeavailable at 8 Java_gnu_io_RXTXPort_open=Java_gnu_io_RXTXPort_open at 12 Java_gnu_io_RXTXPort_readArray=Java_gnu_io_RXTXPort_readArray at 20 Java_gnu_io_RXTXPort_readByte=Java_gnu_io_RXTXPort_readByte at 8 +Java_gnu_io_RXTXPort_readTerminatedArray=Java_gnu_io_RXTXPort_readTerminatedArray at 24 Java_gnu_io_RXTXPort_sendBreak=Java_gnu_io_RXTXPort_sendBreak at 12 Java_gnu_io_RXTXPort_setDSR=Java_gnu_io_RXTXPort_setDSR at 12 Java_gnu_io_RXTXPort_setDTR=Java_gnu_io_RXTXPort_setDTR at 12 -Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_setInputBufferSize=Java_gnu_io_RXTXPort_setInputBufferSize at 12 Java_gnu_io_RXTXPort_setOutputBufferSize=Java_gnu_io_RXTXPort_setOutputBufferSize at 12 Java_gnu_io_RXTXPort_setRTS=Java_gnu_io_RXTXPort_setRTS at 12 +Java_gnu_io_RXTXPort_setflowcontrol=Java_gnu_io_RXTXPort_setflowcontrol at 12 Java_gnu_io_RXTXPort_writeArray=Java_gnu_io_RXTXPort_writeArray at 24 Java_gnu_io_RXTXPort_writeByte=Java_gnu_io_RXTXPort_writeByte at 16 +Java_gnu_io_RXTXVersion_nativeGetVersion=Java_gnu_io_RXTXVersion_nativeGetVersion at 8 From tjarvi at qbang.org Mon Jan 16 19:39:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Jan 2006 19:39:18 -0700 (MST) Subject: [Rxtx] 'latestbuild' directory on qbang. Message-ID: As I go through the work of getting build and test machines together, I'll be scripting the builds to copy libraries to ftp://ftp.qbang.org/pub/rxtx/latestbuild The build system is deliberataly old on the C side. It is easier to be backwards compatable as an OS. If these are too old, they can be moved up a bit but we wont be using gcc4.0. linux i32: gcc 2.96 w32: gcc 2.95 The JDK is default jdk1.5.0_01 I can look at automating more cross builds (*bsd,w64,64bit linux, solaris, ...) as time goes on. Right now I'm just getting stuff together. I have not even tried loading the libraries in latestbuild yet. But you can look if you are having real problems right now or want to help out. They are just the libraries dumped by a script. I'll be doing formal tests later. Sadly they are not scriptable or something that can be shared. I wont be dumping source tars in yet. Just grab the code from CVS. The goal is just to be able to hand people test builds when they have specific problems. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 17 02:15:24 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 17 Jan 2006 10:15:24 +0100 Subject: [Rxtx] More close() performance fixes Message-ID: <1137489324.31899.27.camel@localhost.localdomain> This brings down close() from ~100ms to 1-10ms on a Linux Debian box. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose.txt Type: text/x-patch Size: 2016 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/b850063f/fasterclose-0004.bin From jsmsengine at gmail.com Tue Jan 17 02:58:40 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 11:58:40 +0200 Subject: [Rxtx] Re: Rxtx Digest, Vol 4, Issue 10 In-Reply-To: <200601162327.k0GNR6rF032085@www.qbang.org> References: <200601162327.k0GNR6rF032085@www.qbang.org> Message-ID: <4f8cec620601170158m6dd5e0ceyf0bf936acb949141@mail.gmail.com> Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/aca55f97/attachment-0004.html From jsmsengine at gmail.com Tue Jan 17 03:04:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Tue, 17 Jan 2006 12:04:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Excuse me for the repost, just forgot to add a meaningfull subject line. Sorry :( ---------- Forwarded message ---------- From: jSMSEngine Admin Date: Jan 17, 2006 11:58 AM Subject: Re: Rxtx Digest, Vol 4, Issue 10 To: rxtx at qbang.org Hi all, Trent, I have found something. I read your comment about flow control, so I experimented a bit. If you remember, in my sample program I've used no flow control at all (i.e. Java constant FLOWCONTROL_NONE). Now, during testing, I've switch to hardware inbound flow control (i.e. Java constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! I think I will switch to H/W flow control and test things for a while, but up to now (a few hundred test read cycles) everything runs smoothly. Regards, ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2006 22:16:43 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] Re: Win32 problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > Hi. > > > > No, the code with the bytes does not work either... :( > > > > On Linux, both mine (original) and your code (modified) work fine. > > > > > > > > > > This will have to wait until I get a modem, but What I'd probably look at > is an unused function in termios.c called FillDCB(). This function can be > modified to your liking. Anyplace rxtx does a SetCommState(), just call > FillDCB() instead or comment it out. > > Will FillDCB() you can set the entire windows structure to whatever you > need. From there you can work out just what rxtx is doing wrong. You may > be able to spot what is wrong after seeing the DCB structure and working > back through the code. > > Let me know if you would like an account for building/timkering. > > After looking through the list, Through the archives, I suspect there > is a problem on w32 Flow control related. > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------ -- Thanasis Delenikas http://www.jsmsengine.org -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060117/9a6e849a/attachment-0004.html From tjarvi at qbang.org Tue Jan 17 11:04:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 11:04:37 -0700 (MST) Subject: [Rxtx] More close() performance fixes In-Reply-To: <1137489324.31899.27.camel@localhost.localdomain> References: <1137489324.31899.27.camel@localhost.localdomain> Message-ID: On Tue, 17 Jan 2006, ?yvind Harboe wrote: > This brings down close() from ~100ms to 1-10ms on a Linux Debian box. > > > Hi ?yvind The typical JNI call is going to take 8-12 ms depending upon the OS. I just wonder if setting these to 20 ms would really be that costly to your application functionality. We could poll but I wonder how many other things this will cause problems for. Some applications are going to be trying to do Swing and ... The JNI layer is ~ milliseconds just to go across. The native layer is ~microseconds to get its work done. Sometimes its a safe idea to just let Java do its thing if it does not hurt too much. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 17 12:24:39 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> References: <4f8cec620601170204o3429098byf6504e2c289a1a3c@mail.gmail.com> Message-ID: On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > Hi all, > > Trent, I have found something. > I read your comment about flow control, so I experimented a bit. > > If you remember, in my sample program I've used no flow control at all (i.e. > Java constant FLOWCONTROL_NONE). > > Now, during testing, I've switch to hardware inbound flow control (i.e. Java > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work beautifully! > > I think I will switch to H/W flow control and test things for a while, but > up to now (a few hundred test read cycles) everything runs smoothly. > Hi Thanasis, I'm fairly sure you have identified a bug. I would not worry too much about what Sun CommAPI w32 defaults are. I think they did more or less whatever the port opened with. Just a guess. Linux tries to stomp on ports so they are all the same. So this started out with Linux worked, Windows XP/.. did not as I recall. Something is wrong in rxtx. Do I understand this right? FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. Perhaps there is something Wayne or I did not understand when we wrote that code. I wasnt programming back in the BBS days so modems are not my thing. I have a few questions. Is the above matrix confirmed by observation? Linux just always worked? Which one _should_ work? I'm guessing modems work with hardware flow control. I'll have to dig around. The windows flow control changes a couple things with hardware flow control. Following the w32 API documentation is confusing sometimes. But it looks like Linux could have a bug too. From brian at mbari.org Tue Jan 17 21:46:37 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 17 Jan 2006 20:46:37 -0800 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: <43CDC82D.3010308@mbari.org> Hi All, >> >> I think the idea of a singleton a good choice... didn't no if it >> possible... >> but I you want to obtain a little fix at the loading point... because >> if you >> use threads it could be that the singleton would be loaded twice... >> >> public static CommDriver getInstance() { >> --> if (driver != null) return driver; >> if (isLoaded()) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> return driver; >> } >> return null; >> } >> >> --> because if a thread want to get the driver and it isn't >> initialized yet >> ... driver == null ... and now because he is a thread... it could happen >> that he have to stop and another thread starts and tries to get the >> driver... but it isn't not intialized... he calls isloaded() creates the >> rxtxcommdriver and intialized it... than he stops... and the other >> thread >> starts the same game... and now you have two instance... could give some >> problems?! >> > > This looks great to me. I had noticed Doug's observation before just > in debug logs. Cleaning that up would make enumberation much less of > an overhead. Synchronization for a singleton...yes absolutely! Also, the above code snippet has 3 exit points (i.e. 3 return statements) I believe the code below is the same but is a bit easier to follow. public static synchronized CommDriver getInstance() { if (instance == null && isLoaded()) { instance = new RXTXCommDriver(); instance.initialize(); } return instance; } Also, just a reminder that if isLoaded is returning a member variable that variable should be marked 'volatile'. i.e.... private volatile boolean loaded; private boolean isLoaded() { return loaded; } You guys are probably already aware of that but I just thought I'd throw in my 2 cents Cheers Brian Schlining From tjarvi at qbang.org Tue Jan 17 22:05:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Jan 2006 22:05:42 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Tue, 17 Jan 2006, Brian Schlining wrote: > Hi All, >>> >>> I think the idea of a singleton a good choice... didn't no if it >>> possible... >>> but I you want to obtain a little fix at the loading point... because if >>> you >>> use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>> --> because if a thread want to get the driver and it isn't initialized >>> yet >>> ... driver == null ... and now because he is a thread... it could happen >>> that he have to stop and another thread starts and tries to get the >>> driver... but it isn't not intialized... he calls isloaded() creates the >>> rxtxcommdriver and intialized it... than he stops... and the other thread >>> starts the same game... and now you have two instance... could give some >>> problems?! >>> >> >> This looks great to me. I had noticed Doug's observation before just in >> debug logs. Cleaning that up would make enumberation much less of an >> overhead. > Synchronization for a singleton...yes absolutely! Also, the above code > snippet has 3 exit points (i.e. 3 return statements) I believe the code below > is the same but is a bit easier to follow. > > public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; > } > > Also, just a reminder that if isLoaded is returning a member variable that > variable should be marked 'volatile'. i.e.... > > private volatile boolean loaded; > > private boolean isLoaded() { > return loaded; > } > > You guys are probably already aware of that but I just thought I'd throw in > my 2 cents > Cheers > Brian Schlining Doug has been working hard on this off the list and I hope he will share his work so far for further comments. One thing I'm interested in is the ability to reenumerate the ports. I think this will fit in nicely with whats going on. -- Trent Jarvi tjarvi at qbang.org From adam at grummen.net Wed Jan 18 00:29:22 2006 From: adam at grummen.net (Adam Walsh) Date: Wed, 18 Jan 2006 17:29:22 +1000 Subject: [Rxtx] reconnecting to serial device Message-ID: <43CDEE52.8080609@grummen.net> Hi, I'm trying to reconnect to a serial device after it has lost power then been turned on again. I'm using 2.1-7 on win32. If I try and just call CommPortIdentifier.open() again I get a PortInUseException and if I try and call close() on the port first the thread just hangs. Any ideas? Is there some kind of lock that I need to clear first? Thanks for any help! Adam From tjarvi at qbang.org Wed Jan 18 00:35:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 00:35:24 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CDEE52.8080609@grummen.net> References: <43CDEE52.8080609@grummen.net> Message-ID: On Wed, 18 Jan 2006, Adam Walsh wrote: > Hi, > > I'm trying to reconnect to a serial device after it has lost power then been > turned on again. I'm using 2.1-7 on win32. If I try and just call > CommPortIdentifier.open() again I get a PortInUseException and if I try and > call close() on the port first the thread just hangs. Any ideas? Is there > some kind of lock that I need to clear first? > > Thanks for any help! > The fix for this is in CVS now. http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 18 06:25:15 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 18 Jan 2006 08:25:15 -0500 Subject: [Rxtx] multiple exit points. In-Reply-To: <43CDC82D.3010308@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: Hi All, I did hear that some people don't like multiple exit points. The question remains hotly contested and is probably off-point for this list. Is there a name for the general rule that functions or methods shouldn't have multiple exit points? Perhaps someone would say that this is structured programming and it dates from the 80's. However, beyond the "we always did it this way.." lets keep an open mind. Let's say I have a function which validates an input. I have half a dozen simple tests. My choices are a lot of nested if statements, a status variable or multiple exit points. In some cases multiple exit points leads to simpler clearer code. So, single-return way to do it is int foo(int arg) { ???int result; ???if (x != 0) { ???????. ???????.???? ???????. ???????. ???????. ???????/* calculating result */ ???} ???return result; } The multiple-return approach is int foo(int arg) { ???if (x == 0) return 0; ???. ???. ???. ???. ???. ???return /* calculated result */ } I like the second code better, as it a) expresses the intent clearly; b) if the code takes more than a page, enclosing all of it in the 'if' scope just doesn't look good. The second approach gives code that is easier to read. Oh yes, and it reduces the need for indenting. A single exit point can be a strong suggestion at most. Some people are going to correctly argue that it makes a proof of correctness impossible. I did meet one person correctness proofs for his PhD from MIT. Beyond that, my impression is that proofs of correctness appear to be held as typically impractical in production software houses. Am I wrong about that? Another point is that throwing exceptions in the middle of the code also causes multiple exits. But no one seems to object to this. - DL >Hi All, >>> >>>I think the idea of a singleton a good choice... didn't no if it possible... >>>but I you want to obtain a little fix at the loading point... because if you >>>use threads it could be that the singleton would be loaded twice... >>> >>> public static CommDriver getInstance() { >>> --> if (driver != null) return driver; >>> if (isLoaded()) { >>> driver = new RXTXCommDriver(); >>> driver.initialize(); >>> return driver; >>> } >>> return null; >>> } >>> >>>--> because if a thread want to get the driver and it isn't initialized yet >>>... driver == null ... and now because he is a thread... it could happen >>>that he have to stop and another thread starts and tries to get the >>>driver... but it isn't not intialized... he calls isloaded() creates the >>>rxtxcommdriver and intialized it... than he stops... and the other thread >>>starts the same game... and now you have two instance... could give some >>>problems?! >>> >> >>This looks great to me. I had noticed Doug's >>observation before just in debug logs. >>Cleaning that up would make enumberation much >>less of an overhead. >Synchronization for a singleton...yes >absolutely! Also, the above code snippet has 3 >exit points (i.e. 3 return statements) I believe >the code below is the same but is a bit easier >to follow. > >public static synchronized CommDriver getInstance() { > if (instance == null && isLoaded()) { > instance = new RXTXCommDriver(); > instance.initialize(); > } > return instance; >} > >Also, just a reminder that if isLoaded is >returning a member variable that variable should >be marked 'volatile'. i.e.... > >private volatile boolean loaded; > >private boolean isLoaded() { > return loaded; >} > >You guys are probably already aware of that but >I just thought I'd throw in my 2 cents >Cheers >Brian Schlining > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From paul.klissner at sun.com Wed Jan 18 09:38:49 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Wed, 18 Jan 2006 08:38:49 -0800 Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? Message-ID: <43CE6F19.8050704@sun.com> In Sun's javax.comm distribution "examples" there is a long standing example that shows how to port javax.comm to a platform, and it involves implementing the "CommPortIdentifier" class. It is difficult to justify why the javax.comm architects didn't pin that down as an interface or abstract class, thus seperating the specification from the implementation better. Porters would have then been required to provide their own implementation of CommPortIdentifier. Even so, that wouldn't have been flexible enough for RxTx (a project that is doing a great job of generalizing javax.comm, in spite of the API's limitations). Where I find the javax.comm API uncomfortably restricting is that, while comm port drivers are seen as 'pluggable', only a single driver per javax.comm implementation is accomodated, while port enumeration is even less pluggable. From what I can tell, RxTx's offerings don't include RxTx's own CommPortIdentifier implementation, but instead require that Sun's implementation of CommPortIdentifier to behave statically. RxTx does the platform specific port enumeration work "driver side". It is unfortunate, that due to insufficient API review, CommPortIdentifier lost it's virginity and port mapping got pushed into the "driver" layer; it isn't a good division of responsibility. Between the way Sun architects designed the API and they way RxTx is using it, it appears that CommPortIdentifier, a class of dubious charter, is not actually focal point for customization at all. I'd like mutual acknowledgement between Sun and RxTx that this is indeed the situation. Thanks, Paul From shauvikr at yahoo.com Wed Jan 18 10:24:39 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Wed, 18 Jan 2006 17:24:39 +0000 (GMT) Subject: [Rxtx] Xmodem In-Reply-To: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Message-ID: <20060118172439.926.qmail@web52704.mail.yahoo.com> Am i wrong in Implementing the write command?? --> for(j=0;j<=132;j++) out.write(data[j]); does it matter if i send the packet in this format ?? Is there any problem in calculating the checksum?? --> for(j=0;j<=130;j++){ chksum+=data[j]; Can u find any fundamental problems in my code ?? Please reply... Regards, Shauvik Shauvik Roy Choudhary wrote: Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } ! in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/8e15d0b3/attachment-0004.html From tjarvi at qbang.org Wed Jan 18 11:22:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 11:22:18 -0700 (MST) Subject: [Rxtx] multiple exit points. In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: On Wed, 18 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > I did hear that some people don't like multiple exit points. > The question remains hotly contested and is probably > off-point for this list. > > Is there a name for the general rule that functions or methods shouldn't have > multiple exit points? > Perhaps someone would say that this is structured programming and > it dates from the 80's. However, beyond the "we always did it this way.." > lets keep an open mind. > > Let's say I have a function which validates an input. I have half a dozen > simple tests. My choices are a lot of nested if statements, a status variable > or multiple exit points. In some cases multiple exit points leads to simpler > clearer code. > > So, single-return way to do it is > > int foo(int arg) > { > ???int result; > ???if (x != 0) { > ???????. > ???????.???? > ???????. > ???????. > ???????. > ???????/* calculating result */ > ???} > ???return result; > } > > The multiple-return approach is > > int foo(int arg) > { > ???if (x == 0) return 0; > ???. > ???. > ???. > ???. > ???. > ???return /* calculated result */ > } > > I like the second code better, as it > a) expresses the intent clearly; > b) if the code takes more than a page, enclosing all of it in the 'if' scope > just doesn't look good. The second approach gives code that is easier to > read. > Don't look for gotos in the native code :) The primary goal should always be readablility in open source because it is our goal to have others read the code and mybe contribute after that. Thats my opinion. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:04:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:04:14 -0700 (MST) Subject: [Rxtx] Xmodem In-Reply-To: <20060118172439.926.qmail@web52704.mail.yahoo.com> References: <20060118172439.926.qmail@web52704.mail.yahoo.com> Message-ID: On Wed, 18 Jan 2006, Shauvik Roy Choudhary wrote: > Am i wrong in Implementing the write command?? > --> for(j=0;j<=132;j++) out.write(data[j]); > does it matter if i send the packet in this format ?? > > Is there any problem in calculating the checksum?? > --> for(j=0;j<=130;j++){ > chksum+=data[j]; > > Can u find any fundamental problems in my code ?? > Please reply... > Hi Shauvik I did glance through the xmodem protocol and your code quickly when you last posted but I could not find anything. I don't have time to audit your code. One thing I did long ago (jdk1.02 days) when I made rxtx as part of a GPS program was reverse engineer the Garmin protocol. I did this as follows: Computer 1 <============================> Computer 2 || || Computer 3 Computer 1 and computer 2 worked. They had Garmin software (actually it was two GPSs). Computer 3 just listend to the wires on com1 and 2. I could see the actual bytes on the line then. I would write code to try to do that then replace computer 2 with computer 4 (or put your code on computer 2) which ran the code and watch again. This way you can see what is different. You should be able to do this with 2 computers (com1 com2 on each). Even an old 386 computer can do xmodem with older software packages. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 18 12:25:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:25:45 -0700 (MST) Subject: [Rxtx] RxTx doesn't provide it's own "CommPortIdentifier" class implemenation? In-Reply-To: <43CE6F19.8050704@sun.com> References: <43CE6F19.8050704@sun.com> Message-ID: On Wed, 18 Jan 2006, Paul Klissner wrote: > In Sun's javax.comm distribution "examples" there is a long standing > example that shows how to port javax.comm to a platform, and it > involves implementing the "CommPortIdentifier" class. It is difficult > to justify why the javax.comm architects didn't pin that down as an > interface or abstract class, thus seperating the specification from > the implementation better. Porters would have then been required to > provide their own implementation of CommPortIdentifier. > > Even so, that wouldn't have been flexible enough for RxTx (a project > that is doing a great job of generalizing javax.comm, in spite of the > API's limitations). Where I find the javax.comm API uncomfortably > restricting is that, while comm port drivers are seen as 'pluggable', > only a single driver per javax.comm implementation is accomodated, > while port enumeration is even less pluggable. > > From what I can tell, RxTx's offerings don't include RxTx's own > CommPortIdentifier implementation, but instead require that Sun's > implementation of CommPortIdentifier to behave statically. RxTx does > the platform specific port enumeration work "driver side". It is > unfortunate, that due to insufficient API review, CommPortIdentifier > lost it's virginity and port mapping got pushed into the "driver" > layer; it isn't a good division of responsibility. > > Between the way Sun architects designed the API and they way RxTx > is using it, it appears that CommPortIdentifier, a class of > dubious charter, is not actually focal point for customization at > all. I'd like mutual acknowledgement between Sun and RxTx that > this is indeed the situation. > Hi Paul RXTX 2.1 does have a CommPortIdentifier class so if you wanted we could bring it over to 2.0. I did not think it made sense. The nature by which the arrangement came to be between Sun and rxtx was not entirely planned. RXTX was a _very_ simple design when kevin hester added the jcl. tar -tzvf rxtx-1.02p0.tar.gz drwxr-xr-x root/root 0 1997-03-17 04:56:39 rxtx-0.500/ -rw-r--r-- root/root 3233 1997-03-17 04:16:14 rxtx-0.500/Main.java -rw-r--r-- root/root 1097 1997-03-17 04:03:44 rxtx-0.500/RX.java -rw-r--r-- root/root 790 1997-03-17 04:54:33 rxtx-0.500/INSTALL -rw-r--r-- root/root 2186 1997-03-17 04:48:16 rxtx-0.500/RXTXImp.c -rw-r--r-- root/root 3490 1997-03-17 04:13:24 rxtx-0.500/RXTX.java -rw-r--r-- root/root 1090 1997-03-17 04:04:19 rxtx-0.500/TX.java What was I doing up at 4 am? The goal from this end has alway been to keep the support issues a minimum with Sun Javax Comm. The drawback of not doing CommPortIdentifier in rxtx 2.0 can be seen in rxtx 2.1 CommPort Identifier: public static final int PORT_SERIAL = 1; // rs232 Port public static final int PORT_PARALLEL = 2; // Parallel Port public static final int PORT_I2C = 3; // i2c Port public static final int PORT_RS485 = 4; // rs485 Port public static final int PORT_RAW = 5; // Raw Port -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 18 12:41:48 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 18 Jan 2006 20:41:48 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137613308.14998.14.camel@localhost.localdomain> > Hi yvind > > The typical JNI call is going to take 8-12 ms depending upon the OS. I > just wonder if setting these to 20 ms would really be that costly to your > application functionality. We could poll but I wonder how many other > things this will cause problems for. Some applications are going to be > trying to do Swing and ... > > The JNI layer is ~ milliseconds just to go across. > The native layer is ~microseconds to get its work done. > > Sometimes its a safe idea to just let Java do its thing if it does not > hurt too much. Well... something needs to be done for my application(I've deployed the modifications, I had no choice). 100ms for a close() call just doesn't work out. I suspect read/write could also experience similar delays, but I've chosen to time close(). What if I got rid of the polling altogether? Is there a fundemental reason why polling *must* be used? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 18 12:49:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 12:49:50 -0700 (MST) Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <1137613308.14998.14.camel@localhost.localdomain> References: <200601181733.k0IHXXRF023362@www.qbang.org> <1137613308.14998.14.camel@localhost.localdomain> Message-ID: On Wed, 18 Jan 2006, ?yvind Harboe wrote: >> Hi yvind >> >> The typical JNI call is going to take 8-12 ms depending upon the OS. I >> just wonder if setting these to 20 ms would really be that costly to your >> application functionality. We could poll but I wonder how many other >> things this will cause problems for. Some applications are going to be >> trying to do Swing and ... >> >> The JNI layer is ~ milliseconds just to go across. >> The native layer is ~microseconds to get its work done. >> >> Sometimes its a safe idea to just let Java do its thing if it does not >> hurt too much. > > Well... something needs to be done for my application(I've deployed the > modifications, I had no choice). 100ms for a close() call just doesn't > work out. I suspect read/write could also experience similar delays, but > I've chosen to time close(). > > What if I got rid of the polling altogether? > > Is there a fundemental reason why polling *must* be used? > > Not at all. If you want to implement an event scheme, thats fine. As maintainer, its my job to make sure that those applications that are working don't get worse over time. You can submit a proposed patch for review here and if nobody objects, it will be accepted. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Wed Jan 18 13:56:23 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Wed, 18 Jan 2006 22:56:23 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <310a1a930601181256j77f6a1f6vc5b28233942adc6@mail.gmail.com> Hi all. (I've subscribed again from my other email account). Trent, You are right. Linux *always* works, no matter what flow control you set. Windows *works only* with hardware flow control (I haven't tested what happens with software XON/XOFF flow control). I assume (but I am not certain) that even with no flow control at all, all platforms should work. Without flow control, you have the risk of bumping into overflow or framing errors, but that's your (the end programmer, I mean) problem. >From my side, I shouldn't be working without flow control. That was a bug too... It was some code forgotten from the old times, when I used to work with phone emulation drivers which didn't support flow control. The correct way is to have some flow control enabled and that's why I suppose this is a low-severity bug for RxTx. I have no idea which platform shows the correct behaviour, since my knowledge about Linux and the inner workings of these low-level i/o operations is limited. Regards, Thanasis Delenikas. > Message: 2 > Date: Tue, 17 Jan 2006 12:24:39 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 17 Jan 2006, jSMSEngine Admin wrote: > > > Hi all, > > > > Trent, I have found something. > > I read your comment about flow control, so I experimented a bit. > > > > If you remember, in my sample program I've used no flow control at all ( > i.e. > > Java constant FLOWCONTROL_NONE). > > > > Now, during testing, I've switch to hardware inbound flow control (i.e. > Java > > constant FLOWCONTROL_RTSCTS_IN) and everything seems to work > beautifully! > > > > I think I will switch to H/W flow control and test things for a while, > but > > up to now (a few hundred test read cycles) everything runs smoothly. > > > > > Hi Thanasis, > > I'm fairly sure you have identified a bug. I would not worry too much > about what Sun CommAPI w32 defaults are. I think they did more or less > whatever the port opened with. Just a guess. Linux tries to stomp on > ports so they are all the same. > > So this started out with Linux worked, Windows XP/.. did not as I recall. > Something is wrong in rxtx. Do I understand this right? > > FLOWCONTROL_RTSCTS_NONE: Linux worked, Windows did not. > FLOWCONTROL_RTSCTS_IN: Linux worked, Windows worked. > > Perhaps there is something Wayne or I did not understand when we wrote > that code. I wasnt programming back in the BBS days so modems are not my > thing. I have a few questions. > > Is the above matrix confirmed by observation? > Linux just always worked? > Which one _should_ work? I'm guessing modems work with hardware flow > control. I'll have to dig around. > > The windows flow control changes a couple things with hardware flow > control. Following the w32 API documentation is confusing sometimes. > But it looks like Linux could have a bug too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060118/08e93cf0/attachment-0004.html From adam at grummen.net Wed Jan 18 18:26:45 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 11:26:45 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> Message-ID: <43CEEAD5.8090201@grummen.net> Hi Trent, That fix now allows me to call the close() method (I had to put the try/catch block around nativeDrain as well because the exception is thrown for me when I try and flush the output stream). When I call CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown Application. Any idea why this would be happening? Adam Trent Jarvi wrote: > On Wed, 18 Jan 2006, Adam Walsh wrote: > >> Hi, >> >> I'm trying to reconnect to a serial device after it has lost power >> then been turned on again. I'm using 2.1-7 on win32. If I try and >> just call CommPortIdentifier.open() again I get a PortInUseException >> and if I try and call close() on the port first the thread just >> hangs. Any ideas? Is there some kind of lock that I need to clear first? >> >> Thanks for any help! >> > > The fix for this is in CVS now. > > http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html > From tjarvi at qbang.org Wed Jan 18 18:47:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 18:47:27 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CEEAD5.8090201@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Hi Trent, > > That fix now allows me to call the close() method (I had to put the try/catch > block around nativeDrain as well because the exception is thrown for me when > I try and flush the output stream). When I call > CommPortIdentifier.isCurrentlyOwned() it returns false as expected, but when > I try and open the port again, I'm getting gnu.io.PortInUseException: Unknown > Application. Any idea why this would be happening? > > Adam Thanks Adam I'll look at the nativeDrain and get that in CVS tonight. I figured there would be others when we found that. With the Port Ownership, I never really looked at that beyond putting it in. With rxtx, if you can open the file, it's not owned. The Ownership code is largely unverified. Rxtx uses lockfiles to work well with other programs outside of Java. It would be interesting to go through and get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough to look. There are interesting things that could be done there in the future but right now its once over spaghetti rarely used. It is probably not hard to fix if you want to look at it. > > > Trent Jarvi wrote: >> On Wed, 18 Jan 2006, Adam Walsh wrote: >> >>> Hi, >>> >>> I'm trying to reconnect to a serial device after it has lost power then >>> been turned on again. I'm using 2.1-7 on win32. If I try and just call >>> CommPortIdentifier.open() again I get a PortInUseException and if I try >>> and call close() on the port first the thread just hangs. Any ideas? Is >>> there some kind of lock that I need to clear first? >>> >>> Thanks for any help! >>> >> >> The fix for this is in CVS now. >> >> http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adam at grummen.net Wed Jan 18 21:19:00 2006 From: adam at grummen.net (Adam Walsh) Date: Thu, 19 Jan 2006 14:19:00 +1000 Subject: [Rxtx] reconnecting to serial device In-Reply-To: References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> Message-ID: <43CF1334.4090307@grummen.net> Trent Jarvi wrote: > With the Port Ownership, I never really looked at that beyond putting > it in. With rxtx, if you can open the file, it's not owned. The > Ownership code is largely unverified. Rxtx uses lockfiles to work > well with other > programs outside of Java. It would be interesting to go through and > get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone > enough to look. Does it use lockfiles for win32? I seem to remember seeing a note in some code somewhere saying that it didn't. I'll have a dig around anyway and see what I can find. From tjarvi at qbang.org Wed Jan 18 21:38:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Jan 2006 21:38:44 -0700 (MST) Subject: [Rxtx] reconnecting to serial device In-Reply-To: <43CF1334.4090307@grummen.net> References: <43CDEE52.8080609@grummen.net> <43CEEAD5.8090201@grummen.net> <43CF1334.4090307@grummen.net> Message-ID: On Thu, 19 Jan 2006, Adam Walsh wrote: > Trent Jarvi wrote: >> With the Port Ownership, I never really looked at that beyond putting it >> in. With rxtx, if you can open the file, it's not owned. The Ownership >> code is largely unverified. Rxtx uses lockfiles to work well with other >> programs outside of Java. It would be interesting to go through and >> get PORT_OWNERSHIP_REQUESTED working. It just hasnt itched anyone enough >> to look. > > Does it use lockfiles for win32? I seem to remember seeing a note in some > code somewhere saying that it didn't. I'll have a dig around anyway and see > what I can find. I'm not a win32 guy but from my observations ('forced' for $) the w32 kernel handles this. Win32 is not a problem. Actually while looking at w32 I saw it does some neat things. They had a really great guy doing serial programming. I had to look at w95, 98, nt, xp, .. it was sad watching it slowly degrade. It is still decent though. It is very different from POSIX termios but early on it was _very_ respectable at the rs232 layer. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Thu Jan 19 02:59:11 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Thu, 19 Jan 2006 10:59:11 +0100 Subject: [Rxtx] Re: More close() performance fixes In-Reply-To: <200601181733.k0IHXXRF023362@www.qbang.org> References: <200601181733.k0IHXXRF023362@www.qbang.org> Message-ID: <1137664751.4286.52.camel@localhost.localdomain> How about this one? AFAICT, there was a superfluous synchronization mechanism for waiting for the notification thread to complete which caused the 100ms delay. -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fasterclose2.txt Type: text/x-patch Size: 2336 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060119/feb71cc0/fasterclose2-0005.bin From lyon at docjava.com Thu Jan 19 06:25:48 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 08:25:48 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: Hi All, For those of you who use Mac, Linux or Windows, I am trying a new installer with a Builder and Singleton design pattern for RXTX. In short, it checks for RXTX in the java.library.path. If it cannot find it, it creates: ~/.rxtx And installs the serial native lib there, for your platform. Then, it add the ~/.rxtx to the java.library.path by altering the visibility of the path variable using reflection. Finally, it loads up and displays a dialog (it worked!). Here is the URL: http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp This is pure beta code...just need a few testers to see if this works. Please let me know what platform you are using (I tried this on mac/linux and windows, ONLY). Thanks! - Doug From tjarvi at qbang.org Thu Jan 19 06:42:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Jan 2006 06:42:32 -0700 (MST) Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: On Thu, 19 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > I'd just add I know Doug has been working hard on this for a fair amount of time. It was interesting working with Doug off the list and I was very impressed. I never pictured rxtx.org as a distribution source. I'd like others to do that. rxtx.org is a place for rxtx to improve. Thanks Doug! -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 19 07:13:00 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 19 Jan 2006 15:13:00 +0100 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: All right. Works perfect on my iBook G4 with OS X 10.4.4 :-) Great concept by the way! Am 19.01.2006 um 14:25 schrieb Dr. Douglas Lyon: > Hi All, > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. > > In short, it checks for RXTX in the java.library.path. > If it cannot find it, it creates: > ~/.rxtx > And installs the serial native lib there, for your platform. > > Then, it add the ~/.rxtx to the java.library.path by > altering the visibility of the path variable using reflection. > Finally, it loads up and displays a dialog (it worked!). > Here is the URL: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > gnu.io.SafeCommDriver.jnlp > > This is pure beta code...just need a few testers to see if this works. > Please let me know what platform you are using (I tried this on > mac/linux and windows, ONLY). > > Thanks! > - Doug > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From richardw at geoquip-rnd.demon.co.uk Thu Jan 19 08:20:29 2006 From: richardw at geoquip-rnd.demon.co.uk (richardw@geoquip-rnd.demon.co.uk) Date: Thu, 19 Jan 2006 15:20:29 +0000 Subject: [Rxtx] Testing a new install idea In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> Message-ID: <17359.44605.51621.924434@titanic.geolog> Dr. Douglas Lyon writes: > For those of you who use Mac, Linux or Windows, > I am trying a new installer with a Builder and Singleton > design pattern for RXTX. I've tried it on two machines here - One a fully-patched Windows 2000 box and one running Slackware Linux. Both showed messages suggesting that the process had worked, but I'm not sure exactly what they're supposed to have installed or where. I can't find anything in ~/.rxtx Richard From lyon at docjava.com Thu Jan 19 09:18:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 19 Jan 2006 11:18:26 -0500 Subject: [Rxtx] Testing a new install idea In-Reply-To: <17359.44605.51621.924434@titanic.geolog> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43CB3A88.8030602@mail.island.net> <43CBF197.6010001@sun.com> <17359.44605.51621.924434@titanic.geolog> Message-ID: Hi All, I forgot to mention, This program will only install the native libraries if they are missing from the classpath. If they already appear in the java.library.path, the program does nothing other than display a dialog that says, "it worked!" With multiple versions of native libraries possible, it is not clear, to me, how to manage the variations....or even if we should. RXTXVersion has a hard-coded version string in it. Once it is loaded, it cannot be unloaded. And if the versions don't match, we could always go on a version hunt. Perhaps the version could be coded into the name of the web directory. Any ideas? If the native libs were UUEncoded resources, this resource management issue would be shifted away from the web... Thanks! - Doug >Dr. Douglas Lyon writes: > > For those of you who use Mac, Linux or Windows, > > I am trying a new installer with a Builder and Singleton > > design pattern for RXTX. > >I've tried it on two machines here - One a fully-patched Windows 2000 box >and one running Slackware Linux. Both showed messages suggesting that the >process had worked, but I'm not sure exactly what they're supposed to >have installed or where. I can't find anything in ~/.rxtx > >Richard > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From brian at mbari.org Thu Jan 19 09:57:13 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 19 Jan 2006 08:57:13 -0800 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> Message-ID: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> > > Doug has been working hard on this off the list and I hope he will > share his work so far for further comments. I have an app that talks to VCR's using RS-422. It's multi-threaded and works well with java comm 2.0 but is not so friendly with RXTX (I've tried it with both 2.0 and 2.1). When Doug makes his code changes available I'd be happy to take them for spin and see if I run into any threading problems with it. BTW, The problems I had with RXTX were a) Not getting responses on windows (I suspect this has to do with the flow control setting bug that was recently reported.) b) The classpathx version of the java.comm libraries installed via fink on Mac OS X have some threading issues. My application throws a 'java.lang.IllegalMonitorStateException: current thread not owner', which tells me something isn't synchronized correctly. @ Dr. Douglas Lyon > I did hear that some people don't like multiple exit points. Sorry, I wasn't make myself clear. I wasn't intending on starting a debate about multiple return statements. My point was really that the getInstance method is basically a lazy-initializer. So it's really only doing 2 things 1) Instantiating as instance if needed 2) return the instance. 3 returns seemed like a bit of overkill, that's all. Cheers Brian Schlining From vt at freehold.crocodile.org Thu Jan 19 22:02:21 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 19 Jan 2006 22:02:21 -0700 Subject: [Rxtx] singleton design pattern - caveats and limitations In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: <43D06EDD.3080305@freehold.crocodile.org> Dr. Douglas Lyon wrote: > Hi All, > I see initialize being called more than once in static blocks > contained by the RXTXCommDriver. > > However, it is my understanding that initialize should not > be called more than once. > > More importantly, we need a run-time means to determine > if a driver can be loaded. > > Would it be better design to make use of the Singleton Design Pattern > to obtain an instance of the RXTXCommDriver? [rest skipped for brevity] > Adding the SafeCommDriver to the CommDriver access should do no harm, > and it would > give a central point for checking the existence of the native library > in the load path before throwing an exception. It also makes sure > that initialize is invoked only once. Finally, if the > library is missing, we could offer to install it...at run time, from > a web page. This might make the serial port software more robust. I hope I'm not repeating what someone else may have said (catching up, as usual) - There are pitfalls... - It is possible to have more than one singleton instance per JVM. Sounds ridiculous, but google up "multiple singletons per JVM", you'll see what I mean. There are many possible solutions for this, but they're beyond the scope of this message, except for couple - make an instance listen on a known port, or use a lock file. - JNI libraries can't be loaded more than once per JVM, so in a case like above only the subset loaded by the first class loader will succeed. I believe that the JNI classes will be unavailable to others who try to do it (and access RxTx) later. - Which makes it reasonable to move RxTx stuff into boot classpath, or rather whatever is considered to be the boot by the infrastructure (these problems, as a matter of rule, will pop up only in application containers such as Tomcat, JBoss etc.). > - Doug --vt From lyon at docjava.com Fri Jan 20 01:04:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 03:04:09 -0500 Subject: AW: [Rxtx] singleton design pattern [and synchronization] In-Reply-To: <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> <43CDC82D.3010308@mbari.org> <1F4659CA-A73D-4FC2-A528-25DCB1E0D635@mbari.org> Message-ID: Hi All, I have taken Brian's suggestion to heart: public class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static CommDriver getInstance() { if (driver == null && NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } Does look like better code...(thanks Brian!). I have heard of the multi-return issue in the past and it concerns me that we have no clear resolution on the matter. Perhaps it is too off-point for this list. - Doug >>Doug has been working hard on this off the list and I hope he will >>share his work so far for further comments. > > >I have an app that talks to VCR's using RS-422. It's multi-threaded >and works well with java comm 2.0 but is not so friendly with RXTX >(I've tried it with both 2.0 and 2.1). When Doug makes his code >changes available I'd be happy to take them for spin and see if I >run into any threading problems with it. > >BTW, The problems I had with RXTX were a) Not getting responses on >windows (I suspect this has to do with the flow control setting bug >that was recently reported.) b) The classpathx version of the >java.comm libraries installed via fink on Mac OS X have some >threading issues. My application throws a >'java.lang.IllegalMonitorStateException: current thread not owner', >which tells me something isn't synchronized correctly. > >@ Dr. Douglas Lyon > >>I did hear that some people don't like multiple exit points. > >Sorry, I wasn't make myself clear. I wasn't intending on starting a >debate about multiple return statements. My point was really that >the getInstance method is basically a lazy-initializer. So it's >really only doing 2 things 1) Instantiating as instance if needed 2) >return the instance. 3 returns seemed like a bit of overkill, that's >all. > >Cheers >Brian Schlining > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 20 02:20:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 20 Jan 2006 04:20:01 -0500 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: <43D06EDD.3080305@freehold.crocodile.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: >..... >- It is possible to have more than one singleton instance per JVM. >Sounds ridiculous, but google up "multiple singletons per JVM", >you'll see what I mean. I am not sure how to defeat this, but I have made the getter lazy, with the constructor private and the class final. If someone reloads the SafeCommDriver with a class loader to create a new instance then singleton is defeated. Using a lock file is a possible solution. If this seems like a danger, I have no objection to implementing it. Of course, putting in a lock file can also be fraught with problems. If the JVM exits w/o clearing the lock, we should probably delete it... unless it was created by another JVM that is still running. Ugh. You know, I probably just don't understand the computer science concept well enough. I am just an engineer! More below: >There are many possible solutions for this, but they're beyond the >scope of this message, except for couple - make an instance listen >on a known port, or use a lock file. > >- JNI libraries can't be loaded more than once per JVM, I did not know that! Why is this true? Is there a way around it? Can a new class loader load a different native lib? If not, why not? Sorting out the multiple versions of the RXTX libraries is getting to be more and more difficult..And managing which ones are loaded seems like a good idea (particularly for active developers!). In fact, I think a NativeLibraryResourceManager would be very popular with JNI developers. Isn't that what JNIWrapper tries to do with its customize JNI Class loader? To manage the java.library.path, I had to hack the API with reflection: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } A code inspection shows that altering the java.library.path will otherwise make no difference on which native libs are loaded. Perhaps this is what was meant, and the above is the hack around the limitation. Ya, I know, it puts the UG, in UGLY...but now you can: public static void appendJavaLibraryPath(String p) { try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); } Such code enables the load order to be changed when attempting to add JNI libs to the JVM. Putting RXTX stuff into the boot class path is going to make it global for all users and requires developers to alter files in the boot path in order to change versions. And that is both tedious and error prone. The pathHack technology enables you to alter which version you load, at run-time. For the JNI developer, this is a key feature, IMHO. Thanks for the feedback! - Doug >so in a case like above only the subset loaded by the first class >loader will succeed. I believe that the JNI classes will be >unavailable to others who try to do it (and access RxTx) later. > >- Which makes it reasonable to move RxTx stuff into boot classpath, >or rather whatever is considered to be the boot by the >infrastructure (these problems, as a matter of rule, will pop up >only in application containers such as Tomcat, JBoss etc.). > >> - Doug > >--vt > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From szabo.roland at mithrandir.hu Fri Jan 20 09:42:56 2006 From: szabo.roland at mithrandir.hu (=?ISO-8859-2?Q?Szab=F3_Roland?=) Date: Fri, 20 Jan 2006 17:42:56 +0100 Subject: [Rxtx] 28800 baud under Win32 Message-ID: <43D11310.3060100@mithrandir.hu> Hi! I need to communicate with a device that only supports the baud rate of 28800, nothing else. I was successfull under Linux (I set the baud rate to 38400, and configured the port for custom speed), but the same program run under Windows receives no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 directly). I do know, that the device works on that port and speed, because it has a Windows native test program that can read its status. My guess is that the baud rate is not set correctly. Is there any way to make sure of this, or has anybody successfully used custom baud rates under Windows? In the source it says that windows should take care of custom speeds. I'm using the version 2.1-7pre17. Thanks for any suggestions, Roland From vt at freehold.crocodile.org Fri Jan 20 09:59:57 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 20 Jan 2006 09:59:57 -0700 Subject: [Rxtx] PathHacking around the API bugaboo In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> <43D06EDD.3080305@freehold.crocodile.org> Message-ID: <20060120165957.GA11596@freehold.crocodile.org> On Fri, Jan 20, 2006 at 04:20:01AM -0500, Dr. Douglas Lyon wrote: > >- It is possible to have more than one singleton instance per JVM. > >Sounds ridiculous, but google up "multiple singletons per JVM", > >you'll see what I mean. > > I am not sure how to defeat this, but I have made the getter > lazy, with the constructor private and the class final. If someone > reloads the SafeCommDriver with a class loader to create a new > instance then singleton is defeated. Using a lock file is a possible > solution. > > If this seems like a danger, I have no objection to implementing it. > Of course, putting in a lock file can also be fraught with problems. > If the JVM exits w/o clearing the lock, we should probably delete it... > unless it was created by another JVM that is still running. Ugh. Off the top of my head: I'd prefer to kkeep listening on a known port - that'll take care of a process dying. Besides, other JVMs won't be able to use the port (which, I think, would be the right thing), but then again, it creates incompatibility with other, non-Java applications that use lock files to keep track of the port. Stale lock files can be taken care of, though. Usually the PID is used to do that, I don't remember how to do that from Java, but I guess it is possible. > >- JNI libraries can't be loaded more than once per JVM, > > I did not know that! > Why is this true? Yes :) > Is there a way around it? Not really > Can a new class loader load a different native lib? > If not, why not? Different - yes. Same - no. Again, off the top of my head (it's been a while since I've worked with JNI), there is a possibility you can trick the JVM into thinking it's a different native library by, say, changing the name it's referenced by (a symlink, a hardlink, a physical copy of the library file), but this creates more problems than it solves - why would you want to do it to begin with? > Putting RXTX stuff into the boot class path is going to make it > global for all users and requires developers to alter files in the boot > path in order to change versions. And that is both tedious and error prone. That's not quite what I meant. The boot classpath doesn't necessarily have to be global - it's rather a virtual concept; for java apps, it can be specified with -Xbootclasspath, for application servers it's a configuration item. As for native libraries, yes, there's a good reason they are versioned like they are, and I would guess that it's possible to keep multiple versions of the library installed, with one being the default. > - Doug --vt From tjarvi at qbang.org Fri Jan 20 10:34:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 10:34:20 -0700 (MST) Subject: [Rxtx] 28800 baud under Win32 In-Reply-To: <43D11310.3060100@mithrandir.hu> References: <43D11310.3060100@mithrandir.hu> Message-ID: On Fri, 20 Jan 2006, [ISO-8859-2] Szab? Roland wrote: > Hi! > > I need to communicate with a device that only supports the baud rate of > 28800, nothing else. > > I was successfull under Linux (I set the baud rate to 38400, and configured > the port for custom speed), but the same program run under Windows receives > no answer (I open COM1 instead of /dev/ttyS0, and set the speed to 28800 > directly). I do know, that the device works on that port and speed, because > it has a Windows native test program that can read its status. > > My guess is that the baud rate is not set correctly. Is there any way to make > sure of this, or has anybody successfully used custom baud rates under > Windows? In the source it says that windows should take care of custom > speeds. I'm using the version 2.1-7pre17. > This is a problem in windows. If you dont beat me to it, I'll be fixing it shortly. This is the 'dark corner' of how rxtx does windows. Termios does not work. Linux does so there is a baudbase divisor hack for linux. This has to be reversed on the windows side (termios.c) and just passed to the API. But right now, you are right. It isnt working. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 20 15:09:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 20 Jan 2006 15:09:19 -0700 (MST) Subject: [Rxtx] fair warning Message-ID: I'm seriously looking at working for a company doing rxtx like things. This is an obvious conflict of interest. I suspect the process will take about a month. I want to keep rxtx its own thing and the company concerned is interested in that too. I just want to be fair and mention it at this point. -- Trent Jarvi tjarvi at qbang.org From trevor at opecsystem.com Mon Jan 23 12:37:21 2006 From: trevor at opecsystem.com (Trevor Sutton) Date: Mon, 23 Jan 2006 19:37:21 -0000 Subject: [Rxtx] Serial operation for USB serial ports on linux Message-ID: <000001c62054$6dda1bb0$2b001eac@aries> Hi Can anybody give me a few pointers on where in the c code is the best place to look for serial rx interrupts? The problem I have is linux box with an usb to eight serial ports board. I know the usb/serial hardware works using minicom and a loopback. I know my code works for ports /dev/ttyS0 to Sn. However when using my code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, but I don't seem to get any data available event. Trevor Sutton; Managing Director OpecSystem Limited Mobile 07768 461940 Office 01296 730110 Email Trevor at opecsystem.com www. opecsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060123/2e6234fa/attachment-0004.html From tjarvi at qbang.org Mon Jan 23 13:09:50 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 23 Jan 2006 13:09:50 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: <000001c62054$6dda1bb0$2b001eac@aries> References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: On Mon, 23 Jan 2006, Trevor Sutton wrote: > Hi > > Can anybody give me a few pointers on where in the c code is the best > place to look for serial rx interrupts? > > The problem I have is linux box with an usb to eight serial ports board. > I know the usb/serial hardware works using minicom and a loopback. I > know my code works for ports /dev/ttyS0 to Sn. However when using my > code, based upon rxtx2.1, with the /dev/ttyUSB ports, it transmits ok, > but I don't seem to get any data available event. > Hi Trevor The data available event goes down to a bit on RS232 UARTS. There is a line status register (LSR) at address 5 on the UART chip that at byte 0 has a "Data Ready" slot. The UART flips this when data is available. By reading this bit, the kernel can know when data is available. The problem is USB ports don't have UARTs. In rxtx, this is obtained by ioctl( eis->fd, FIONREAD, &change ) except for OpenServer and Solaris (perhaps other traditional Unix systems too). The return value of select() is used to know. It looks like rxtx just returns data available on these system when the file descriptor changes. So this appears to be a bit problematic with USB. I know output buffer empty is also a problem (which you work around with flush()). How this will behave is going to depend upon the kernel drivers. They need to try to do what can be done on UARTs. They probably can do it all but sometimes code is written that just gets a certain job done. One place to start looking to see if you can get the results you want is to just put your thumb on SELECT() in RXTXPort(eventLoop). This should break out as soon as there is a detectable change on the port. The other option is to go with polling reads with long timeouts and short thresholds. I suspect this is how minicom is doing it. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 24 08:58:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Jan 2006 08:58:56 -0700 (MST) Subject: [Rxtx] Serial operation for USB serial ports on linux In-Reply-To: References: <000001c62054$6dda1bb0$2b001eac@aries> Message-ID: > There is a line status register (LSR) at address 5 on the UART chip that at > byte 0 has a "Data Ready" slot. The UART flips this when data is available. > By reading this bit, the kernel can know when data is available. The problem > is USB ports don't have UARTs. > This does not really relate to the discussion but I was not accurate and who knows who will find it looking for what. Its an address offset of 1 not 5. From f.frumento at ngi.it Wed Jan 25 08:18:53 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Wed, 25 Jan 2006 16:18:53 +0100 Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 Message-ID: <43D796DD.7000804@ngi.it> Hi all, I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial port on WindowsXP pro with a ThinkPadT43P from IBM while the bytes are being written and read correctly it thrown an IO exception in the native method writeArray (but the byte are sent ok), i've tried to compile the RXTX myself to debug properly and understand what is causing this strange behavior, but it seems i'm not skilled enough to make it compile with cygwin :( ok I could catch the exception and continue to work but i don't like to work with a piece of code i can't understand the behavior of, anyway it seems the guilty row is at SerialImpl.c:1342 ---- code } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); ---- code for some reason (result < 0 && errno==EINTR ) return false also after sending the right amount of bytes. this problem exists only with the bluetooth serial (not sure for USB) if i use a normal legacy RS232 port it works fine anyone else have experienced same problem ? Could someone kindly tell me how to compile this little monster with cygwin or also mingwin so that i can debug it myself ? i've follwed instruction in the tarball but neither the java or C code is being compiled, i've checked against the most common mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to check... Thanks in advance Fabio Frumento From tjarvi at qbang.org Wed Jan 25 10:52:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 25 Jan 2006 10:52:19 -0700 (MST) Subject: [Rxtx] Problem with bluetooth COM and rxtx 2.1-7pre17 In-Reply-To: <43D796DD.7000804@ngi.it> References: <43D796DD.7000804@ngi.it> Message-ID: On Wed, 25 Jan 2006, Fabio Frumento wrote: > Hi all, > > I'm experiencing some problem using rxtx 2.1-7pre17 with a bluetooth serial > port on WindowsXP pro with a ThinkPadT43P from IBM > > while the bytes are being written and read correctly it thrown an IO > exception in the native method writeArray (but the byte are sent ok), i've > tried to compile the RXTX myself to debug properly and understand what is > causing this strange behavior, but it seems i'm not skilled enough to make it > compile with cygwin :( > > ok I could catch the exception and continue to work but i don't like to work > with a piece of code i can't understand the behavior of, anyway it seems the > guilty row is at SerialImpl.c:1342 > ---- code > } while ( ( total < count ) && (result < 0 && errno==EINTR ) ); > ---- code > > for some reason (result < 0 && errno==EINTR ) return false also after sending > the right amount of bytes. this problem exists only with the bluetooth serial > (not sure for USB) if i use a normal legacy RS232 port it works fine > > anyone else have experienced same problem ? Could someone kindly tell me how > to compile this little monster with cygwin or also mingwin so that i can > debug it myself ? i've follwed instruction in the tarball but neither the > java or C code is being compiled, i've checked against the most common > mistakes (JAVA_PATH, INCLUDE PATH and so on) and now i don't know what to > check... > Hi Fabio, You will probably be following this into termios.c and serial_write to find out what is really going on. There is a YACK macro that can be used to describe the w32 API errors in win32termios.h. When people have problems compiling w32, I usually offer them the 'bob' account. This allows people to upload their code and cross compile to windows on a linux system. If you are interested, just contact me off the list. Getting mingw builds going can be tricky if you have not done it before. If you like, you may paste the build errors you are having to the list and we can try to figure out whats wrong. -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 17:02:55 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 16:02:55 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I've moved from a Windows box to a Linux box running Fedora Core 2 and JDK 1.5.0_03. On Trent's suggestion I'm running the latest RXTX-2.1-7pre20, have specified the flow control (none) and have specified the read timeout (disabled). When I run the attached code I get the following exception: Java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) at SerialIfTest.runTest(SerialIfTest.java:143) at SerialifTest.main(SerialIfTest.java:22) Attached are the make command, the run command, the test results, and the code. Any assistance would be appreciated. I'm a really green Linux user. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: maketest Type: application/octet-stream Size: 123 bytes Desc: maketest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/maketest-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: runtest Type: application/octet-stream Size: 119 bytes Desc: runtest Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/runtest-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testresults Type: application/octet-stream Size: 485 bytes Desc: testresults Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/testresults-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SerialIfTest.java Type: application/octet-stream Size: 6557 bytes Desc: SerialIfTest.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060127/227d9a76/SerialIfTest-0004.obj From tjarvi at qbang.org Fri Jan 27 17:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 17:22:16 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Fri Jan 27 18:04:50 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 17:04:50 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 - ttyS103. ls -lH /dev/ttyS100 crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 We're using a 9 pin connector. Hopefully you'll just tell me it's a cabling error because the pinout came from Digi and is built to spec. statserial -n /dev/ttyS100 Device: /dev/ttyS100 Signal Pin Pin Direction Status Full Name (25) (9) (computer) Name ----- --- --- --------- ------ ----- FG 1 - - - Frame Ground TxD 2 3 out - Transmit Data RxD 3 2 in - Receive Data RTS 4 7 out 1 Request To Send CTS 5 8 in 0 Clear To Send DSR 6 6 in 0 Data Set Ready GND 7 5 - - Signal Ground DCD 8 1 in 0 Data Carrier Detect DTR 20 4 out 0 Data Terminal Ready RI 22 9 in 0 Ring Indicator setserial -a /dev/ttyS100 Cannot get serial info: Invalid argument I tried setserial with no params and the only other format it presented was setserial -g -a /dev/ttyS100 which gave the same results. I suspect all of this is because it's a virtual port. dmesg | grep -i serial Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled Thanks for the quick response. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 4:22 PM To: RXTX Developers and Users Subject: Re: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > I've moved from a Windows box to a Linux box running Fedora Core 2 and > JDK 1.5.0_03. On Trent's suggestion I'm running the latest > RXTX-2.1-7pre20, have specified the flow control (none) and have > specified the read timeout (disabled). When I run the attached code I > get the following exception: > > > > Java.io.IOException: Input/output error in writeArray > > at gnu.io.RXTXPort.writeArray(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) > > at SerialIfTest.runTest(SerialIfTest.java:143) > > at SerialifTest.main(SerialIfTest.java:22) > > > > Attached are the make command, the run command, the test results, and > the code. Any assistance would be appreciated. I'm a really green > Linux user. > > > String portName = "/dev/ttyS100"; Do you really have 101 serial ports? If so could you give the output of ls -lH /dev/ttyS100 statserial -n /dev/ttyS100 setserial -a /dev/ttyS100 dmesg | grep -i serial Usually, COM2 is ttyS1 -- 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 Fri Jan 27 18:35:51 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 18:35:51 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 CMorpeth at osec.com Fri Jan 27 19:02:53 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Fri, 27 Jan 2006 18:02:53 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: Inline... -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 5:36 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray On Fri, 27 Jan 2006, Morpeth, Chris wrote: > We're using a Digi PortServer so we have 4 "virtual" ports from ttyS100 > - ttyS103. > > ls -lH /dev/ttyS100 > crw------- 1 root root 253, 0 Jan 27 16:07 /dev/ttyS100 > Maybe this relates to the virtual port driver but those major and minor numbers dont look right to me. MAKEDEV /dev/ttyS100 crw-rw---- 1 root uucp 4, 164 Jan 27 18:39 /dev/ttyS100 I assume you are running this as root then? Thats the only user that can read and write to that port. [CM] Yes, everything is run as root. > We're using a 9 pin connector. Hopefully you'll just tell me it's a > cabling error because the pinout came from Digi and is built to spec. I doubt that. But the error suggests a low level write problem. > > statserial -n /dev/ttyS100 > Device: /dev/ttyS100 > > Signal Pin Pin Direction Status Full > Name (25) (9) (computer) Name > ----- --- --- --------- ------ ----- > FG 1 - - - Frame Ground > TxD 2 3 out - Transmit Data > RxD 3 2 in - Receive Data > RTS 4 7 out 1 Request To Send > CTS 5 8 in 0 Clear To Send > DSR 6 6 in 0 Data Set Ready > GND 7 5 - - Signal Ground > DCD 8 1 in 0 Data Carrier Detect > DTR 20 4 out 0 Data Terminal Ready > RI 22 9 in 0 Ring Indicator Looks like a serial port. > > setserial -a /dev/ttyS100 > Cannot get serial info: Invalid argument Hmm. Probably missing ioctls (TIOCGSERIAL?) in the virtual ports. Just a guess but that just means no custome baud rates (which are not working anyhow). strace -eioctl setserial -a /dev/ttyS100 any ioctl call returning something other than 0 failed. [CM] ioctl(3, TIOCGSERIAL, 0x7ffffff57f7f70) = -1 EINVAL (Invalid argument) Cannot get serial info: Invalid argument > > I tried setserial with no params and the only other format it presented > was setserial -g -a /dev/ttyS100 which gave the same results. I suspect > all of this is because it's a virtual port. nods > > dmesg | grep -i serial > Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing > enabled Thats just the UART on the mb. Have you tried the system port just to see how its going? With multiport cards, make sure you have the latest driver. The onboard UARTs get tested silly in linux. The multiport options? .. [CM] Nope. But I'll be out of town until next Thursday and won't get to try it until then. In the mean time I'll check with Digi to see if they have any clues. But they're admittedly Java ignorant so not much hope there. This may be a simple case of the virtual ports almost being like a serial port and there is some deficiency in the driver thats possible to work around on our end. If thats the case, maybe digi could provide us with some hints. Try the PC UART though. > > Thanks for the quick response. > > Chris > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Friday, January 27, 2006 4:22 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] I/O error in writeArray > > On Fri, 27 Jan 2006, Morpeth, Chris wrote: > >> I've moved from a Windows box to a Linux box running Fedora Core 2 and >> JDK 1.5.0_03. On Trent's suggestion I'm running the latest >> RXTX-2.1-7pre20, have specified the flow control (none) and have >> specified the read timeout (disabled). When I run the attached code I >> get the following exception: >> >> >> >> Java.io.IOException: Input/output error in writeArray >> >> at gnu.io.RXTXPort.writeArray(Native Method) >> >> at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1137) >> >> at SerialIfTest.runTest(SerialIfTest.java:143) >> >> at SerialifTest.main(SerialIfTest.java:22) >> >> >> >> Attached are the make command, the run command, the test results, and >> the code. Any assistance would be appreciated. I'm a really green >> Linux user. >> >> >> > > String portName = "/dev/ttyS100"; > > Do you really have 101 serial ports? If so could you give the output of > > ls -lH /dev/ttyS100 > statserial -n /dev/ttyS100 > setserial -a /dev/ttyS100 > dmesg | grep -i serial > > Usually, COM2 is ttyS1 > > -- > 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 tjarvi at qbang.org Fri Jan 27 19:32:38 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 27 Jan 2006 19:32:38 -0700 (MST) Subject: [Rxtx] I/O error in writeArray In-Reply-To: References: Message-ID: runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- Trent Jarvi tjarvi at qbang.org From CMorpeth at osec.com Sat Jan 28 11:16:00 2006 From: CMorpeth at osec.com (Morpeth, Chris) Date: Sat, 28 Jan 2006 10:16:00 -0800 Subject: [Rxtx] I/O error in writeArray Message-ID: I have more data. In order to ensure that the native code prints appear in order I added a 5 second sleep at the front of the test. I already had 5 second sleeps between each write. I also added flush() calls after each write(). Now the JNI_OnLoad appears before the "Devel Library" line. The exception, however, occurs after the THIRD write() rather than after the fourth. AND, if I increase the sleep between the writes from 5 seconds to 10 seconds the exception occurs after the SECOND write. So it seems as if there's some timeout occurring rather than something related to the AMOUNT of data being written. Again, I'll try using the hardware serial port instead of this virtual serial port next Thursday or see if I can get someone else to do it for me before I get back in town. Thanks. Chris -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Friday, January 27, 2006 6:33 PM To: RXTX Developers and Users Subject: RE: [Rxtx] I/O error in writeArray runTest: Configuring port /dev/ttyS100 Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Command: 81 01 06 52 14 14 00 00 00 00 00 00 00 00 00 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 04 02 01 0d 00 0c 03 05 00 ff Command: 81 01 06 52 14 14 00 03 01 09 05 00 0c 03 05 00 ff runTest: IO Exception (/dev/ttyS100). Experimental: JNI_OnLoad called. The strange thing is it appears the first 3 writes did work. The JNI_OnLoad is the native library loading. The messages are always out of order when the native code prints. It looks like the first 3 writes had to complete to get that far though. The message you showed off the list which I assume was the execption message is from the C library saying write() just failed. Just an idea but you may try to flush() after the write(). -- 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 Jan 28 11:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 11:50:11 -0700 (MST) Subject: [Rxtx] RXTX 2.1.7 Release Options. Message-ID: I'll be going through and adding the patches (2?) that have been submitted and nobody complained about today. My schedual is going to be a bit goofy. May is probably the earliest full testing can be done here. That said, I think the rxtx 2.1 code we currently have in CVS is going to help many projects. My thoughts are we should release 2.1.7 this weekend as is. This will really help projects like debian that only take the 'solid' releases. I have a list of ~20 tasks I'll be going through. Much of this is going to involve confirmation of bugs or no bugs using test hardware. This work can be released as rxtx 2.1.8 in ~May. Would anyone object to this? -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 13:32:24 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 15:32:24 -0500 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: Hi I added file LibSerialUniversal.xcodeproj.sitx.hqx into the CVS's folder rxtx-devel/MACOSX_IDE/PB this is a XCode 2.2.1 project for building universal libraries I didn't test built libraries (I don't have the appropriate hardware) enjoy Dmitry Markman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060128/077bb5d1/attachment-0004.html From tjarvi at qbang.org Sat Jan 28 14:20:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 14:20:05 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi > I added file LibSerialUniversal.xcodeproj.sitx.hqx > into the CVS's folder rxtx-devel/MACOSX_IDE/PB > > this is a XCode 2.2.1 project for building universal libraries > I didn't test built libraries (I don't have the appropriate hardware) > > enjoy > Thanks Dmitry With the Mac OS X, we have the build tree with binaries in rxtx source. Would you be interested in rebuilding that tree tomorrow or early next week so they have 2.1.7 binaries in the tree? I could also put those in the binary package for people like Doug working on installers then. The auto* tools should also work with Mac OS X now too. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 15:16:20 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 17:16:20 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Hi, Trent how I can access that tree? I can't see it inside of the rxtx-devel folder thanks On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi >> I added file LibSerialUniversal.xcodeproj.sitx.hqx >> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >> >> this is a XCode 2.2.1 project for building universal libraries >> I didn't test built libraries (I don't have the appropriate hardware) >> >> enjoy >> > > Thanks Dmitry > > With the Mac OS X, we have the build tree with binaries in rxtx > source. Would you be interested in rebuilding that tree tomorrow or > early next week so they have 2.1.7 binaries in the tree? I could > also put those in the binary package for people like Doug working > on installers then. > > The auto* tools should also work with Mac OS X now too. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 15:24:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 15:24:01 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: Hi Dmitry With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was thinking of the following: rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib These tend to be older releases if we dont sync and some folks pull them out for installs. I still need to get two patches in today but it will be ready first thing tomorrow for sure. On Sat, 28 Jan 2006, Dmitry Markman wrote: > Hi, Trent > > how I can access that tree? > I can't see it inside of the rxtx-devel folder > > thanks > > > On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: > >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi >>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>> >>> this is a XCode 2.2.1 project for building universal libraries >>> I didn't test built libraries (I don't have the appropriate hardware) >>> >>> enjoy >>> >> >> Thanks Dmitry >> >> With the Mac OS X, we have the build tree with binaries in rxtx source. >> Would you be interested in rebuilding that tree tomorrow or early next week >> so they have 2.1.7 binaries in the tree? I could also put those in the >> binary package for people like Doug working on installers then. >> >> The auto* tools should also work with Mac OS X now too. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 16:20:53 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 18:20:53 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> Message-ID: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> well I already did it (but I think the name should be librxtxSerial.jnilib, at least RXTXPort class has static initialization that call System.loadLibrary( "rxtxSerial" ) ) problem is that that library will be good only for mac os x 10.4 and higher it probably won't work for 10.3 or 10.2 also I didn't check that library, so if somebody can do that I'd be very grateful thanks however CVS has the file LibSerial.pbproj.sit.hqx that contains the project that builds binaries for the 10.3 and 10.2 On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > > Hi Dmitry > > With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I > was thinking of the following: > > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > > These tend to be older releases if we dont sync and some folks pull > them out for installs. > > I still need to get two patches in today but it will be ready first > thing tomorrow for sure. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> Hi, Trent >> >> how I can access that tree? >> I can't see it inside of the rxtx-devel folder >> >> thanks >> >> >> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >> >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi >>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>> this is a XCode 2.2.1 project for building universal libraries >>>> I didn't test built libraries (I don't have the appropriate >>>> hardware) >>>> enjoy >>> Thanks Dmitry >>> With the Mac OS X, we have the build tree with binaries in rxtx >>> source. Would you be interested in rebuilding that tree tomorrow >>> or early next week so they have 2.1.7 binaries in the tree? I >>> could also put those in the binary package for people like Doug >>> working on installers then. >>> The auto* tools should also work with Mac OS X now too. >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 16:30:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 16:30:16 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: Hi Dmitry Perhaps we should doing a cvs delete on a few files. For instance: $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar differ $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar [] $ find rxtx-devel/ -name \*.jnilib rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/libSerial.jnilib rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib I think this could lead to confusion. it looks like there are multiple copies and some are outdated. When people run into problems they tend to become rather random in behavior. Eliminating obvious bad choices would help. On Sat, 28 Jan 2006, Dmitry Markman wrote: > well > I already did it (but I think the name should be librxtxSerial.jnilib, at > least > RXTXPort class has static initialization that call > System.loadLibrary( "rxtxSerial" ) ) > > problem is that that library will be good only for mac os x 10.4 and higher > it probably won't work for 10.3 or 10.2 > > also I didn't check that library, so if somebody can do that > I'd be very grateful > > thanks > > > however CVS has the file LibSerial.pbproj.sit.hqx that contains the project > that builds > binaries for the 10.3 and 10.2 > > On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: > >> >> Hi Dmitry >> >> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I was >> thinking of the following: >> >> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >> Extensions/libSerial.jnilib >> >> These tend to be older releases if we dont sync and some folks pull them >> out for installs. >> >> I still need to get two patches in today but it will be ready first thing >> tomorrow for sure. >> >> On Sat, 28 Jan 2006, Dmitry Markman wrote: >> >>> Hi, Trent >>> >>> how I can access that tree? >>> I can't see it inside of the rxtx-devel folder >>> >>> thanks >>> >>> >>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>> >>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>> Hi >>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>> this is a XCode 2.2.1 project for building universal libraries >>>>> I didn't test built libraries (I don't have the appropriate hardware) >>>>> enjoy >>>> Thanks Dmitry >>>> With the Mac OS X, we have the build tree with binaries in rxtx source. >>>> Would you be interested in rebuilding that tree tomorrow or early next >>>> week so they have 2.1.7 binaries in the tree? I could also put those in >>>> the binary package for people like Doug working on installers then. >>>> The auto* tools should also work with Mac OS X now too. >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> Dmitry Markman >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From dmarkman at mac.com Sat Jan 28 17:10:18 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 19:10:18 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: since CodeWarrior is officially dead I removed all CW directory from the CVS Trent, please, remove CW directory from the server I removed file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/libSerial.jnilib as well however file rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/ Java/Extensions/librxtxSerial.jnilib is untested and should be good only for 10.4.X on PPC or Intel On Jan 28, 2006, at 6:30 PM, Trent Jarvi wrote: > > Hi Dmitry > > Perhaps we should doing a cvs delete on a few files. For instance: > $ diff ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > Binary files ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar and ./rxtx- > devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar differ > $ ls -l ./rxtx-devel/MACOSX_IDE/CW/RXTXcomm.jar ./rxtx-devel/ > MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/ > RXTXcomm.jar > -rw-r--r-- 1 root root 126488 Sep 23 2004 ./rxtx-devel/MACOSX_IDE/ > CW/RXTXcomm.jar > -rw-r--r-- 1 root root 111646 Jan 28 04:26 ./rxtx-devel/MACOSX_IDE/ > ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar > [] $ find rxtx-devel/ -name \*.jnilib > rxtx-devel/MACOSX_IDE/CW/libI2C.jnilib > rxtx-devel/MACOSX_IDE/CW/libParallel.jnilib > rxtx-devel/MACOSX_IDE/CW/libRS485.jnilib > rxtx-devel/MACOSX_IDE/CW/librxtxSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/libSerial.jnilib > rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ > Extensions/librxtxSerial.jnilib > > I think this could lead to confusion. it looks like there are > multiple copies and some are outdated. When people run into > problems they tend to become rather random in behavior. > Eliminating obvious bad choices would help. > > On Sat, 28 Jan 2006, Dmitry Markman wrote: > >> well >> I already did it (but I think the name should be >> librxtxSerial.jnilib, at least >> RXTXPort class has static initialization that call >> System.loadLibrary( "rxtxSerial" ) ) >> >> problem is that that library will be good only for mac os x 10.4 >> and higher >> it probably won't work for 10.3 or 10.2 >> >> also I didn't check that library, so if somebody can do that >> I'd be very grateful >> >> thanks >> >> >> however CVS has the file LibSerial.pbproj.sit.hqx that contains >> the project that builds >> binaries for the 10.3 and 10.2 >> >> On Jan 28, 2006, at 5:24 PM, Trent Jarvi wrote: >> >>> Hi Dmitry >>> With rxtx 2.1 (using cvs checkout -r commapi-0-0-1 rxtx-devel) I >>> was thinking of the following: >>> rxtx-devel/MACOSX_IDE/ForPackageMaker/Install/Library/Java/ >>> Extensions/libSerial.jnilib >>> These tend to be older releases if we dont sync and some folks >>> pull them out for installs. >>> I still need to get two patches in today but it will be ready >>> first thing tomorrow for sure. >>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>> Hi, Trent >>>> how I can access that tree? >>>> I can't see it inside of the rxtx-devel folder >>>> thanks >>>> On Jan 28, 2006, at 4:20 PM, Trent Jarvi wrote: >>>>> On Sat, 28 Jan 2006, Dmitry Markman wrote: >>>>>> Hi >>>>>> I added file LibSerialUniversal.xcodeproj.sitx.hqx >>>>>> into the CVS's folder rxtx-devel/MACOSX_IDE/PB >>>>>> this is a XCode 2.2.1 project for building universal libraries >>>>>> I didn't test built libraries (I don't have the appropriate >>>>>> hardware) >>>>>> enjoy >>>>> Thanks Dmitry >>>>> With the Mac OS X, we have the build tree with binaries in rxtx >>>>> source. Would you be interested in rebuilding that tree >>>>> tomorrow or early next week so they have 2.1.7 binaries in the >>>>> tree? I could also put those in the binary package for people >>>>> like Doug working on installers then. >>>>> The auto* tools should also work with Mac OS X now too. >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> Dmitry Markman >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> Dmitry Markman >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From dmarkman at mac.com Sat Jan 28 19:46:56 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sat, 28 Jan 2006 21:46:56 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: I made the following changes in the CVS: (2.1) folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources file RXTX.pre_install was deleted files preinstall and preupgrade was added file preinstall and preupgrade handle /var/lock directory (as SerialImp.h suggests) folder rxtx-devel/MACOSX_IDE/ForPackageMaker file RXTX_Tiger.pmproj.sitx.hqx that file is an installer project (Tiger) file RXTX_Tiger.pkg.sitx.hqx this file is an installer itself I tested that installer on my iMac G5 (10.4.4) and it worked well also I tested (very lightly) jnilib and it looks like it works too but extensive testing is still required (currently I have just keyspan adapter, but I don't have any device, so I just tested that rxtx recognizes serial port without errors) that installer contains universal library so in theory it should work on intel's Macintosh Dmitry Markman From tjarvi at qbang.org Sat Jan 28 19:54:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 19:54:49 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: <24138A8B-A962-4D43-975E-5771B33E2BA0@mac.com> <68325EEB-7923-4583-ACBA-2A53D539B264@mac.com> Message-ID: On Sat, 28 Jan 2006, Dmitry Markman wrote: > I made the following changes in the CVS: > (2.1) > folder rxtx-devel/MACOSX_IDE/ForPackageMaker/Resources > file RXTX.pre_install was deleted > files preinstall and preupgrade was added > > file preinstall and preupgrade handle /var/lock directory > (as SerialImp.h suggests) > > folder rxtx-devel/MACOSX_IDE/ForPackageMaker > > file RXTX_Tiger.pmproj.sitx.hqx > that file is an installer project (Tiger) > > file RXTX_Tiger.pkg.sitx.hqx > this file is an installer itself > > I tested that installer on my iMac G5 (10.4.4) > and it worked well > > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh > Neat Dmitry As all changes are going to happen in RXTXPort.java, I can just sneak a jar into the Mac OS X tree when I make those changes so we are all on the same boat in the release. 1) a close speeup fix 2) a flush fix so close does not hang. I'll post with links (when I find them :) shortly. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Jan 28 21:49:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 21:49:03 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 Message-ID: We are quickly comming to the release of 2.1-7. This will probably be the last release before may. There are many little fixes that will help users. While it has not been formally tested, I'm confident this release will be one of the best yet. I think these will be the last changes before 2.1-8. Does anyone know of something missing? I'll do builds in the morning. I need to read through the last patch one more time but this is whats going down. 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html I looks like we will have binaries for the following platforms initially x86-w32 x86-linux x86_64-linux arm-linux (pending cross tools) mips-linux (pending cross tools) ppc-linux (pending cross tools) ppc-Mac OS X x86-Mac OS X Sparc Solaris (pending permission - no cc installed) If you would like to work with us getting more platforms into the mix, please bounce and email. Some that should work but we dont have build tools for: w64 (gnu tools are not there yet) hp-ux (I may have access to one of these without cc) aix irix dec unix x86 Solaris unixware openunix wince (this needs closed source tools) *bsd (I could do this on a slow day) others I may have missed. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sat Jan 28 22:42:52 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 00:42:52 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: small comment Apple doesn't use x86 notation it uses i386 (and BTW it has nothing to do with i386 set of command it's just notion of the intel processor in general, so don't be afraid :-) ) so I'd recommend i386-Mac OS X instead of x86-Mac OS X but it's not that important I think thanks On Jan 28, 2006, at 11:49 PM, Trent Jarvi wrote: > > We are quickly comming to the release of 2.1-7. This will probably > be the last release before may. There are many little fixes that > will help users. While it has not been formally tested, I'm > confident this release will be one of the best yet. > > I think these will be the last changes before 2.1-8. Does anyone > know of something missing? I'll do builds in the morning. I need > to read through the last patch one more time but this is whats > going down. > > 2.1-7 Jan 29 2006 > Mac OS X x86/universal binaries/install fixes > Dmitry Markman > http://mailman.qbang.org/pipermail/rxtx/ > 20060128/002169.html > catch exceptions on flush() so close() works. > Adam Walsh > http://mailman.qbang.org/pipermail/rxtx/ > 20060118/002131.html > more close() performance fixes > ?yvind Harboe > http://mailman.qbang.org/pipermail/rxtx/ > 20060119/002135.html > > I looks like we will have binaries for the following platforms > initially > > x86-w32 > x86-linux > x86_64-linux > arm-linux (pending cross tools) > mips-linux (pending cross tools) > ppc-linux (pending cross tools) > ppc-Mac OS X > x86-Mac OS X > Sparc Solaris (pending permission - no cc installed) > > If you would like to work with us getting more platforms into the > mix, please bounce and email. Some that should work but we dont > have build tools for: > > w64 (gnu tools are not there yet) > hp-ux (I may have access to one of these without cc) > aix > irix > dec unix > x86 Solaris > unixware > openunix > wince (this needs closed source tools) > *bsd (I could do this on a slow day) > others I may have missed. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Dmitry Markman From tjarvi at qbang.org Sat Jan 28 22:54:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 28 Jan 2006 22:54:33 -0700 (MST) Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dmitry Markman wrote: > small comment > Apple doesn't use x86 notation > it uses i386 (and BTW it has nothing to do with i386 set of command it's just > notion of the intel processor in general, so don't be afraid :-) ) > so I'd recommend i386-Mac OS X instead of x86-Mac OS X > but it's not that important I think > Nods. What does gcc -dumpmachine say? Thats how I try to split up the binaries not with the source. -- Trent Jarvi tjarvi at qbang.org From dmarkman at mac.com Sun Jan 29 06:54:07 2006 From: dmarkman at mac.com (Dmitry Markman) Date: Sun, 29 Jan 2006 08:54:07 -0500 Subject: [Rxtx] Summary of Changes for Jan 28 In-Reply-To: References: Message-ID: <022D2DF9-20DD-4916-86F1-EE5D20C1BB6D@mac.com> for ppc version it returns powerpc-apple-darwin8 I don't have intel's mac, so I sent questio ti the xcode list and I got answer from Alexander von Below below at mac dot com % gcc -dumpmachine i686-apple-darwin8 On Jan 29, 2006, at 12:54 AM, Trent Jarvi wrote: > Nods. What does gcc -dumpmachine say? Thats how I try to split up > the binaries not with the source. Dmitry Markman From lyon at docjava.com Sun Jan 29 07:07:23 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 29 Jan 2006 09:07:23 -0500 Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: Hi All, Is it possible to do a build for all the binaries for all the platforms from a single platform? For example, suppose you are on Linux, then typing "make" should enable the creation of the binaries for each supported platform. At present, if I want to make for the mac, I have to be on a mac. This enables the different versions of the source code in Java to drift away from the different versions of the source code in C. Such a drift is a fruitful source of bugs. Thanks! - Doug From tjarvi at qbang.org Sun Jan 29 11:03:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 11:03:12 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: On Sun, 29 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is it possible to do a build for all the binaries for all > the platforms from a single platform? > > For example, suppose you are on Linux, > then typing "make" should enable the creation > of the binaries for each supported platform. > > At present, if I want to make for the mac, I have to be > on a mac. This enables the different versions of the source > code in Java to drift away from the different versions of > the source code in C. > > Such a drift is a fruitful source of bugs. > Hi Doug Yes and no :) The gcc toolchain is fairly good at compiling to various hosts. This can be configured as a cross toochaing along with glibc and binutils. But the question becomes 'which versions?' You can see some neat work done a while ago looking at just a few targets here: http://kegel.com/crosstool/crosstool-0.38/buildlogs/ Thats just linux. Platforms that dont use glibc are especially problematic because the host libraries are needed which usually means obtaining a closed source product license for the entire operating system. But you can build a cross compiler to Mac OS X. You may run into tiny bugs in gcc depending upon the version (I'd probably try 3.4.5). You probably wont find it premade. This is way to much for discussion on the rxtx list. See the Crossgcc FAQ, the crosstool above and when you run into problems (which always happens) the gurus with tell you "Just THINK!!!" It is fun if you get it working though :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 16:23:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 16:23:17 -0700 (MST) Subject: [Rxtx] universal binaries for Mac OS X In-Reply-To: References: Message-ID: >> At present, if I want to make for the mac, I have to be >> on a mac. This enables the different versions of the source >> code in Java to drift away from the different versions of >> the source code in C. >> >> Such a drift is a fruitful source of bugs. >> > One solution to this is to nfs/smb/afs mount your home directory so you are always using the same code. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 20:18:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 20:18:57 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: We have been working on pre 2.1.7 for some time :) Would it cause less confusion if we call it 2.1.8? I'm about ready to tag and release the source. The bins I'm working on. If nobody comments I'll just go with 2.1.7. Its going to take a while to find the loopback to test a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jan 29 23:55:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Jan 2006 23:55:26 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 Message-ID: Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Mon Jan 30 02:29:56 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Mon, 30 Jan 2006 11:29:56 +0200 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. Message-ID: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Hi Trent, all. I have reports of the following error: When using RXTX on Windows, connecting to a virtual COMM port that passes through a Bluetooth connection, the following exception appears: <<< Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. Exception in thread "main" java.io.IOException: No error in nativeDrain at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1193) at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) at org.jsmsengine.CATHandler.sync(CATHandler.java:59) at org.jsmsengine.CService.connect(CService.java:333) at ReadMessages.main(ReadMessages.java:54) Error 0x1 at /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor rect function. >>> The same exception appears again and again in each read/write cycle, although it seems that the operation is succesful, i.e. exception is thrown but the data gets read correctly. I still cannot reproduce it here, since I have some other, unrelated problems with my bluetooth adapter on my laptop, but I will try to reproduce it and give you more info if required. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/b0dc52ec/attachment-0004.html From ideiglenes1 at freemail.hu Mon Jan 30 02:55:58 2006 From: ideiglenes1 at freemail.hu (=?ISO-8859-2?Q?Ill=E9s_P=E1l_Zolt=E1n?=) Date: Mon, 30 Jan 2006 10:55:58 +0100 (CET) Subject: [Rxtx] rxtx-2.1-7 + my project Message-ID: Great news! This means I can remove the patched version from my project tree. I will check this out ASAP! :) Please add my project to the projects using RXTX, if you think so: http://remotej.sourceforge.net Trent Jarvi ?rta: > > Many thanks to all that have contributed to rxtx-2.1-7! > ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From f.frumento at ngi.it Mon Jan 30 03:09:17 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 11:09:17 +0100 Subject: [Rxtx] Win32 / Bluetooth via COMxx exception. In-Reply-To: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> References: <310a1a930601300129l5d90a982k534ccd70318db884@mail.gmail.com> Message-ID: <43DDE5CD.1080306@ngi.it> Hi Thanasis, If you send some step by step on How to reproduce the problem (configuration used and so on) i can set-up some tests, i'm currently using a bluetooth adapter and it's working fine for me, but i'm using the simplest configuration (No Flow control, no parity, 1 stopbit and 8 databits @38400). Let me know Regards Fabio Frumento PS: To Trent, i'm a bit in late with my code review but i've not forgot it, currently i'm writing alot of docs for my projects (i hate to write docs...) Thanasis Delenikas wrote: > Hi Trent, all. > > I have reports of the following error: > > When using RXTX on Windows, connecting to a virtual COMM port that > passes through a Bluetooth connection, the following exception appears: > > <<< > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > > Exception in thread "main" java.io.IOException: No error in > nativeDrain > at gnu.io.RXTXPort.nativeDrain(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java :1193) > at org.jsmsengine.CSerialDriver.send(CSerialDriver.java:146) > at org.jsmsengine.CATHandler.sync(CATHandler.java:59) > at org.jsmsengine.CService.connect(CService.java:333) > at ReadMessages.main(ReadMessages.java :54) > Error 0x1 at > /home/bob/rxtx-2.1-CVS-20050120/build/../src/termios.c(2505): Incor > rect function. > >>> > > The same exception appears again and again in each read/write cycle, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly. > > I still cannot reproduce it here, since I have some other, unrelated > problems with my bluetooth adapter on my laptop, but I will try to > reproduce it and give you more info if required. > > Regards, > Thanasis. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Scott.Hughes at dalsemi.com Mon Jan 30 09:44:09 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:44:09 -0600 Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Trent, > We have been working on pre 2.1.7 for some time :) > > Would it cause less confusion if we call it 2.1.8? > I like jumping to 2.1.8. I've been telling people who have problems with the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or later. If someone reports a problem, it saves a lot of time if they tell me they are using 2.1.8, versus telling me that they are on 2.1.7 with a followup question to make sure they are using the actual release. From my perspective, most all of my users are running from CVS or one of the 'pre' bins, so a new version number will help me disambiguate. Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From Scott.Hughes at dalsemi.com Mon Jan 30 09:50:33 2006 From: Scott.Hughes at dalsemi.com (Scott Hughes) Date: Mon, 30 Jan 2006 10:50:33 -0600 Subject: [Rxtx] universal binaries for Mac OS X Message-ID: <1809DA15308DD51180EE00508BCF21942E7BBBF5@misnts1.dalsemi.com> Dmitry, > also I tested (very lightly) jnilib and it looks like it works too > but extensive testing is still required > (currently I have just keyspan adapter, but I don't have any device, > so I just tested that rxtx recognizes serial port without errors) > > that installer contains universal library > so in theory it should work on intel's Macintosh I have a MacBook Pro on order and when it arrives (in ~3 weeks) I'll eagerly test your new library. Thanks for contributing the unversial binary! Scott -- Scott Hughes - Engineer Shughes aht dalsemi daut com Maxim/Dallas Semiconductor From tjarvi at qbang.org Mon Jan 30 09:55:21 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 09:55:21 -0700 (MST) Subject: [Rxtx] rxtx 2.1.7 or 2.1.8? In-Reply-To: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> References: <1809DA15308DD51180EE00508BCF21942E7BBBD0@misnts1.dalsemi.com> Message-ID: On Mon, 30 Jan 2006, Scott Hughes wrote: > Trent, > >> We have been working on pre 2.1.7 for some time :) >> >> Would it cause less confusion if we call it 2.1.8? >> > > I like jumping to 2.1.8. I've been telling people who have problems with > the 1-Wire stuff to make sure they are using the bins marked 2.1.7pre17 or > later. If someone reports a problem, it saves a lot of time if they tell me > they are using 2.1.8, versus telling me that they are on 2.1.7 with a > followup question to make sure they are using the actual release. From my > perspective, most all of my users are running from CVS or one of the 'pre' > bins, so a new version number will help me disambiguate. > Well it will be easier to do another release. But I released 2.1.7 so its done. One thing I did do is have the library print out Stable instead of Devel on load. If we get 4 or 5 small patches in for fixes not features, we can do 2.1.8. I'll label it as "2.1.7" Final on the web pages to help clear that confusion up a little. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 10:01:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:01:03 -0700 (MST) Subject: [Rxtx] Java USB Observations. Message-ID: On a side note, I was looking at Java USB as a subset of material to do a technical presentation on. IBM went nuts on design with other companies. It is interesting to read but what I found curious is their web pages 'smell' like rxtx. So we have the professionals trying to look like hobby guys: http://javax-usb.org/ And we have the hobby guys trying to look like professionals: http://jusb.sourceforge.net/ The professionals (perhaps overly) engineered their design but lack the low levelwork. The hobby guys (perhaps underly) engineered their design but have the low level work. I see people doing major school projects as contributions in areas like w32 which Java is often lacking in. And neither talk to each other it appears because of the JCP which places the process behind ivory towers. I've seen Sun claim this as a success of JCP but it appears to be a failure to me even though it did involve other companies. Sad observation. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 10:24:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 10:24:03 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <20060130172403.GA10728@freehold.crocodile.org> On Mon, Jan 30, 2006 at 10:01:03AM -0700, Trent Jarvi wrote: > > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > > So we have the professionals trying to look like hobby guys: > http://javax-usb.org/ > > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > > Sad observation. Sad indeed. I've tried to push the jUSB to the best of my abilities, but didn't get anywhere far. Switched to javax-usb later, and though I'm only using it on Linux, I should say that indeed, your observation is correct - it's architected better and supports more abstractions than jUSB. My guess is that David is extremely busy and jUSB just slipped out of his priority list. Regardless, javax-usb is a better candidate to work off today. Quality is decent, never had a problem with stability (my app easily having uptime measured in months). Just my $0.02... > Trent Jarvi --vt From lucas at negaverse.org Mon Jan 30 10:28:51 2006 From: lucas at negaverse.org (Lucas Madar) Date: Mon, 30 Jan 2006 12:28:51 -0500 Subject: [Rxtx] I/O error in writeByte on win32 Message-ID: <43DE4CD3.1090506@negaverse.org> Hey everyone, I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP (with the latest service packs and updates). I'm able to read data from the serial port just fine, but any attempt to send any data (even a byte) results in an I/O error. writeByte() actually succeeds the first time as the external device *does* receive the data. I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any serial ports. I've tried multiple different USB-to-Serial adapters and each yield the same result. The serial port is set to 9600/8N1, with no flow control. Serial traffic is absolutely minimal, with probably a maximum of 3 bytes per second in either direction. Is this a known issue? Is rxtx supported on this platform? Is rxtx still an active project? I've tried debugging the latest available source code, but the current version of mingw32 seems to be unable to compile the .h files generated by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you recommend? Thanks, Lucas Madar From tjarvi at qbang.org Mon Jan 30 10:38:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 10:38:31 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: On Mon, 30 Jan 2006, Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to send > any data (even a byte) results in an I/O error. writeByte() actually succeeds > the first time as the external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and each > yield the same result. The serial port is set to 9600/8N1, with no flow > control. Serial traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still an > active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated by > javah in the 1.5.0 jdk. Is there a particular version of mingw32 that you > recommend? > Hi Lucas RXTX is fairly active in devel. USB serial dongles are rather new in the mix. I know they have worked in Linux an Mac OS X. I'm not sure about w32. That looks like something I could test too when I have a chance. I do have a dongle now. For your debugging I would use ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip We released it yesterday but I have not put official bins together yet so it will be announced this week sometime. For compiling I use mingw/cygwin gcc 2.95. It is old but sufficient. My latest build (which should not be considered the released bins) is here if you just want to see if its fixed. ftp://ftp.qbang.org/pub/rxtx/lastbuild/ -- Trent Jarvi tjarvi at qbang.org From g.telkamp at domologic.de Mon Jan 30 10:48:29 2006 From: g.telkamp at domologic.de (Gerrit Telkamp) Date: Mon, 30 Jan 2006 18:48:29 +0100 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: Message-ID: <11114696093.20060130184829@domologic.de> We looked for a javax.usb implementation as well and we came to the same result - there is currently no really useful Java-Library for USB available. javax-usb.org seems to run on Linux maxhines only, but on windows we failed. jusb.sourceforge.net seems to run partial on Windows machines, but there is no Linux implementation available. BTW, we had no luck when we tried to test jusb.sourceforge.net. In my opinion the easiest & most promising way to get a platform-independent library for USB is to write a JNI wrapper for libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based library for Linux, with the goal to create a library for use by user level applications to access USB devices - regardless of OS (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, OpenBSD, Darwin and MacOS X are supported. A windows port is also available at http://libusb-win32.sourceforge.net. Having a look into the CVS, both projects seems to be very active. Ok, to get compatible to the Java Specification Request 80 might be difficult going this way, but libusb is more probising than the "offical" way. I have not noticed much activity at javax-usb.org during the last month(s), and there was nothing going on at http://jusb.sourceforge.net/ during the last years... Gerrit. > On a side note, I was looking at Java USB as a subset of material to do a > technical presentation on. IBM went nuts on design with other companies. > It is interesting to read but what I found curious is their web pages > 'smell' like rxtx. > So we have the professionals trying to look like hobby guys: > http://jusb.sourceforge.net/ > And we have the hobby guys trying to look like professionals: > http://jusb.sourceforge.net/ > The professionals (perhaps overly) engineered their design but lack the > low levelwork. > The hobby guys (perhaps underly) engineered their design but have the low > level work. I see people doing major school projects as contributions in > areas like w32 which Java is often lacking in. > And neither talk to each other it appears because of the JCP which places > the process behind ivory towers. I've seen Sun claim this as a success of > JCP but it appears to be a failure to me even though it did involve other > companies. > Sad observation. > -- > 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 Mon Jan 30 11:10:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 11:10:45 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: Hmm. It would take a couple evenings to just wrap the native code and expose their methods. Then people could glue it to either API as possible. Maybe start a dialog with more resources. On Mon, 30 Jan 2006, Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. > > >> On a side note, I was looking at Java USB as a subset of material to do a >> technical presentation on. IBM went nuts on design with other companies. >> It is interesting to read but what I found curious is their web pages >> 'smell' like rxtx. > >> So we have the professionals trying to look like hobby guys: >> http://jusb.sourceforge.net/ > >> And we have the hobby guys trying to look like professionals: >> http://jusb.sourceforge.net/ > >> The professionals (perhaps overly) engineered their design but lack the >> low levelwork. > >> The hobby guys (perhaps underly) engineered their design but have the low >> level work. I see people doing major school projects as contributions in >> areas like w32 which Java is often lacking in. > >> And neither talk to each other it appears because of the JCP which places >> the process behind ivory towers. I've seen Sun claim this as a success of >> JCP but it appears to be a failure to me even though it did involve other >> companies. > >> Sad observation. > >> -- >> 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 dacker at nomadio.net Mon Jan 30 11:16:32 2006 From: dacker at nomadio.net (David S. Acker) Date: Mon, 30 Jan 2006 13:16:32 -0500 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> Message-ID: <001b01c625c9$4ca87340$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under > Windows XP (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any > attempt to send any data (even a byte) results in an I/O > error. writeByte() actually succeeds the first time as the > external device *does* receive the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the > T43 lacks any serial ports. I've tried multiple different > USB-to-Serial adapters and each yield the same result. The > serial port is set to 9600/8N1, with no flow control. Serial > traffic is absolutely minimal, with probably a maximum of 3 > bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx > still an active project? > 1.9.2.54 of termios.c included a fix for a similar issue I saw on windows. In it, USB to serial adapters would finish their I/O synchronously. The code up to that point had assumed that any synchronous return was an error. This patch fixed the interpretation fo the return value and error code to handle serial devices that handle I/O synchronously. -Ack From f.frumento at ngi.it Mon Jan 30 11:50:10 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 19:50:10 +0100 Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE4CD3.1090506@negaverse.org> References: <43DE4CD3.1090506@negaverse.org> Message-ID: <43DE5FE2.5080508@ngi.it> Hi Lucas, I've built the Rxtx with mingw after some troubles, here you can find attached my makefile, hope this is not a problem for the mailing list I'm using the CURRENT release with following packages: MSYS 1.0.10: http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download Install this first then unpack the following files in the \1.0\mingw I've installed msys in C:\ so it is "C:\msys\1.0\mingw" executable files should install properly theirself... ("should") http://prdownloads.sf.net/mingw/mingw-runtime-3.9.tar.gz?download http://prdownloads.sf.net/mingw/mingw-utils-0.3.tar.gz?download http://prdownloads.sf.net/mingw/autoconf-2.59-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/automake-1.9.5-mingwPORT.tar.bz2?download http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-3.exe?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz?download My Java 1.5.0_06 is installed under C:\Programmi\Java\JDK1.5.0_06 So check the PATHS and let me know if any problem arise... once the makefile is PATH-corrected in the project's root folder run: make and then make i686-pc-mingw32/rxtxSerial.d Regards Fabio Frumento Lucas Madar wrote: > Hey everyone, > > I'm experiencing serious problems using rxtx 2.1-7pre17 under Windows XP > (with the latest service packs and updates). > > I'm able to read data from the serial port just fine, but any attempt to > send any data (even a byte) results in an I/O error. writeByte() > actually succeeds the first time as the external device *does* receive > the data. > > I'm using a USB to Serial adapter on a ThinkPad T43 as the T43 lacks any > serial ports. I've tried multiple different USB-to-Serial adapters and > each yield the same result. The serial port is set to 9600/8N1, with no > flow control. Serial traffic is absolutely minimal, with probably a > maximum of 3 bytes per second in either direction. > > Is this a known issue? Is rxtx supported on this platform? Is rxtx still > an active project? > > I've tried debugging the latest available source code, but the current > version of mingw32 seems to be unable to compile the .h files generated > by javah in the 1.5.0 jdk. Is there a particular version of mingw32 that > you recommend? > > Thanks, > Lucas Madar > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.zip Type: application/zip Size: 6797 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060130/a1f752b0/Makefile-0004.zip From tjarvi at qbang.org Mon Jan 30 12:00:03 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:00:03 -0700 (MST) Subject: [Rxtx] I/O error in writeByte on win32 In-Reply-To: <43DE5FE2.5080508@ngi.it> References: <43DE4CD3.1090506@negaverse.org> <43DE5FE2.5080508@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Lucas, > > I've built the Rxtx with mingw after some troubles, here you can find > attached my makefile, hope this is not a problem for the mailing list One thing with those Makefiles, I suspect the bit below can be replaced with newer dll tools doing away with the need for sed and grep. It is an ancient hack. There was another issue with them but I cant rembember the details. I think the build is using a bin format that is not guaranteed to be supported in the future by gcc/w32. Maybe Wayne Roberts will remember. He was the one that mentioned it. echo EXPORTS >$(DEST)/Serial.def;for i in `nm $(DEST)/rxtxSerial.dll | grep "T _Java"|cut -b 13-`;do echo -n $$i|sed s#@.*##;echo "="$$i;done >> $(DEST)/Serial.def The w32 Makefiles have always been problematic. One recommendation is to avoid spaces in your paths. Escaping the spaces is an interesting problem depending upon what your environment is. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:15:00 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:15:00 +0100 Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: References: Message-ID: <1138648500.23903.2.camel@localhost> Hello! Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a tar.gz format for the release. Linux users surely will appreciate. I've repackaged for my local tailored gentoo ebuild, and if you make it public, I would send it into bugs.gentoo.org for maintainer of rxtx ebuild. (Or errr, is this person on this list? :) ) Thanx, Paul From f.frumento at ngi.it Mon Jan 30 12:04:24 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Mon, 30 Jan 2006 20:04:24 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> Message-ID: <43DE6338.6030406@ngi.it> Hi Trent, What do you think about moving the .java files to src/gnu/io folder ? I'm asking this because i'm using eclipse IDE and it complain about having the package gnu.io declaration and not having the files in the "correct" java-style folder hierarchy, what changes are required to the autoconf and automake configuration files ? Moving the files should make easier deal with development tools such as IDE, ANT and so on... if you're thinking about the CVS problem of loosing the files histories SVN could be an option... I'm using it with lot of projects and i never had a problem (yes, I've touched wood and iron after last statement...) Regards Fabio Frumento From tjarvi at qbang.org Mon Jan 30 12:09:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:09:30 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <1138648500.23903.2.camel@localhost> References: <1138648500.23903.2.camel@localhost> Message-ID: On Mon, 30 Jan 2006, -- wrote: > Hello! > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > tar.gz format for the release. Linux users surely will appreciate. I've > repackaged for my local tailored gentoo ebuild, and if you make it > public, I would send it into bugs.gentoo.org for maintainer of rxtx > ebuild. (Or errr, is this person on this list? :) ) > I thought about this. I guess I can. The reason I didn't is you can grab the files fairly easily: jar -tf rxtx-2.1-7.zip for instance. That works on all operating systems. If you still need it for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar -xf foo.zip would not be much though and you need java to build. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 12:23:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:23:59 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: <43DE6338.6030406@ngi.it> References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- Trent Jarvi tjarvi at qbang.org From ideiglenes1 at freemail.hu Mon Jan 30 12:47:34 2006 From: ideiglenes1 at freemail.hu (--) Date: Mon, 30 Jan 2006 20:47:34 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650362.23905.5.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> Message-ID: <1138650454.23905.7.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) > > > > On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > > On Mon, 30 Jan 2006, -- wrote: > > > > > Hello! > > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > > tar.gz format for the release. Linux users surely will appreciate. I've > > > repackaged for my local tailored gentoo ebuild, and if you make it > > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > > ebuild. (Or errr, is this person on this list? :) ) > > > > > > > I thought about this. > > > > I guess I can. The reason I didn't is you can grab the files fairly > > easily: > > > > jar -tf rxtx-2.1-7.zip > > > > for instance. That works on all operating systems. If you still need it > > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > > -xf foo.zip would not be much though and you need java to build. > > > > -- > > 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 Mon Jan 30 12:50:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 12:50:01 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: <1138650454.23905.7.camel@localhost> References: <1138648500.23903.2.camel@localhost> <1138650362.23905.5.camel@localhost> <1138650454.23905.7.camel@localhost> Message-ID: Hi Paul SRC_URI="ftp://jarvi.dsl.frii.com/pub/rxtx/${NP}.zip" I would use ftp://ftp.qbang.org/pub/rxtx/${NP}.zip Yes the massive rxtx community project :) hangs off a DSL line but there is a good chance I'll be moving. qbang.org will then go to a colo and that URL will no longer work. On Mon, 30 Jan 2006, -- wrote: > > Okay, its working with zip too easily to complain about gzip. I have > already posted the ebuild here: > http://bugs.gentoo.org/show_bug.cgi?id=120962 > > Feel free to test it gentoo users. (please :) ) > So nevermind the tar.gz, if noone else is in favour of it! > Anyway thanks! :) >> >> >> >> On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: >>> On Mon, 30 Jan 2006, -- wrote: >>> >>>> Hello! >>>> Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a >>>> tar.gz format for the release. Linux users surely will appreciate. I've >>>> repackaged for my local tailored gentoo ebuild, and if you make it >>>> public, I would send it into bugs.gentoo.org for maintainer of rxtx >>>> ebuild. (Or errr, is this person on this list? :) ) >>>> >>> >>> I thought about this. >>> >>> I guess I can. The reason I didn't is you can grab the files fairly >>> easily: >>> >>> jar -tf rxtx-2.1-7.zip >>> >>> for instance. That works on all operating systems. If you still need it >>> for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar >>> -xf foo.zip would not be much though and you need java to build. >>> >>> -- >>> 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 paul.klissner at sun.com Mon Jan 30 20:31:12 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 30 Jan 2006 19:31:12 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DEDA00.6090005@sun.com> Gerrit Telkamp wrote: > We looked for a javax.usb implementation as well and we came to the > same result - there is currently no really useful Java-Library for USB > available. javax-usb.org seems to run on Linux maxhines only, but on > windows we failed. jusb.sourceforge.net seems to run partial on > Windows machines, but there is no Linux implementation available. BTW, > we had no luck when we tried to test jusb.sourceforge.net. > > In my opinion the easiest & most promising way to get a > platform-independent library for USB is to write a JNI wrapper for > libusb (maybe using the gnu.io.*-namespace?). "libusb" is a C-based > library for Linux, with the goal to create a library for use by user > level applications to access USB devices - regardless of OS > (http://libusb.sourceforge.net). Currently Linux, FreeBSD, NetBSD, > OpenBSD, Darwin and MacOS X are supported. A windows port is also > available at http://libusb-win32.sourceforge.net. Having a look into > the CVS, both projects seems to be very active. > > Ok, to get compatible to the Java Specification Request 80 might be > difficult going this way, but libusb is more probising than the > "offical" way. I have not noticed much activity at javax-usb.org > during the last month(s), and there was nothing going on at > http://jusb.sourceforge.net/ during the last years... > > Gerrit. Javax.usb/libusb is already in the works. However, libusb 0.1.x) (the released version of libusb) does not have all the necessary features to support javax.usb, yet, and we have been working with Johaness Erdfelt on the libusb 1.0 specification, which will fully support javax.usb. This collaboration has been very slow going. Hopefully Johannes will publish the 1.0 API proposal to the libusb mail list soon. Feel free to jump in on that list to help expedite that. javax.usb/libusb will be an *awesome* offering to the hobbying and professional community. It's time has come. >>On a side note, I was looking at Java USB as a subset of material to do a >>technical presentation on. IBM went nuts on design with other companies. >>It is interesting to read but what I found curious is their web pages >>'smell' like rxtx. I was a participant on the JSR-80 (javax.usb) expert group. IBM, the Spec. Lead seeded it with a reference implementation and pretty much called the shots. Other companies negotiated, and I argued some areas on behalf of our Sun Ray thin client platform; finally we got some of the fat trimmed. Having said that, IBM offers a reference implementation layer that simplifies the porting considerably, thus removing perhaps the biggest complaint you have of them "going nuts on the design". USB is complex, there is no doubt about it, and a good API will reflect some of that. If you doubt that, take a good hard look at the USB 2.0 specification, and then consider a class driver specification or three. The API has a lot of nice features and isn't hard to use given its size. IBM put a lot of thought and hard work into it. >>So we have the professionals trying to look like hobby guys: >>http://jusb.sourceforge.net/ The authors of the spec/RI were very bright, talented and motivated people and they were sincere advocates of Open Source. Both pretty fresh out of school and just really "into it". There could have been more restraint. But I think being right out of school, they were driven by their passions more than the bottom line, schedule, or minimalism. I didn't see any pretense whatsoever. I don't believe anyone was 'trying to look like' anything. And, frankly, I don't think that matters or should matter. I think the *quality of the work* is what should be important to serious developers, hobbiests, and professionals alike. >>And we have the hobby guys trying to look like professionals: >>http://jusb.sourceforge.net/ > > >>The professionals (perhaps overly) engineered their design but lack the >>low levelwork. "Lack the low level work?" What does that mean exactly? Do you mean experience? The javax.usb dist has three layers... anyone is free to dispense with IBM's native layer and roll their own. Those guys were Java fiends, and dead serious about writing excellent Java code and well architected APIs. As I mentioned above, any over-engineering is mitigated with an Open Source implementation layer that handles all the platform-independent stuff. The hardest part of implementing it, I found, was dealing with the topology management. It's not a cakewalk, that's for sure, and it is, and the topological requirements are one reason libusb 1.0 needs to be released, ASAP. >>The hobby guys (perhaps underly) engineered their design but have the low >>level work. I see people doing major school projects as contributions in >>areas like w32 which Java is often lacking in. > > >>And neither talk to each other it appears because of the JCP which places >>the process behind ivory towers. I've seen Sun claim this as a success of >>JCP but it appears to be a failure to me even though it did involve other >>companies. > > >>Sad observation. The JCP isn't perfect, and neither are some open source projects. Every system has it's drawbacks and tradeoffs. There were issues because, naturally, in any effort like that, there are competing interests. The JCP is bound and determined to release complete, tested and testable, functional well-considered projects. That always involves some blood sweat and tears. To do any job well takes time. That's just a fact. The process is there for a reason. Often when one does things the hard way life gets easier, while taking the easy way makes life harder. Personally, I don't like paying dues for an allegedly 'finished' product that wasn't refined through some rigor. I think IBM's spec Lead. engineers did an overall very good job on javax.usb, and worked very hard to understand the corner cases and leave no stone unturned. Having said that, I think the API could have been a bit leaner and meaner, but, like a luxury car, some of those features are nice to have. Paul From tjarvi at qbang.org Mon Jan 30 21:12:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:12:34 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DEDA00.6090005@sun.com> References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: Gerrit is on the list so I removed him from the cc. > "Lack the low level work?" What does that mean exactly? Do you mean > experience? Hi Phil No. What I was thinking about when I said that was this: http://www.steelbrothers.ch/jusb/ This is (was?) the start of the big missing component in javax.usb and jusb. If I read things correctly, the JCP did like I've seen before; blindside projects like a 600 lb barnie the dinosaur flinging its tail in a china shop. The 600 lb barnie is easy to get used to. Its the blindsiding that takes the steam out of projects. The point isnt that the specification is incorrect. I'm just seeing lots of pieces not come together. A more inclusive process probably would have had a very different outcome. I'm glad to see libusb is being considered. That looks like a good option. I was looking at the API this afternoon thinking about giving it a spin. Its all for not without windows though. I think I saw IBM has an internal project but thats not very interesting from this end. Thats the low level bits that are missing from what I could see. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Jan 30 21:41:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Jan 2006 21:41:43 -0700 (MST) Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: On Mon, 30 Jan 2006, Trent Jarvi wrote: >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > Hi Phil > Paul: My apologies for getting your name wrong. It was not intentional. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Mon Jan 30 23:30:08 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Mon, 30 Jan 2006 23:30:08 -0700 Subject: [Rxtx] Java USB Observations. In-Reply-To: <11114696093.20060130184829@domologic.de> References: <11114696093.20060130184829@domologic.de> Message-ID: <43DF03F0.5030604@freehold.crocodile.org> Gerrit Telkamp wrote: [preserved for context] >We looked for a javax.usb implementation as well and we came to the >same result - there is currently no really useful Java-Library for USB >available. javax-usb.org seems to run on Linux maxhines only, but on >windows we failed. jusb.sourceforge.net seems to run partial on >Windows machines, but there is no Linux implementation available. BTW, >we had no luck when we tried to test jusb.sourceforge.net. > >In my opinion the easiest & most promising way to get a >platform-independent library for USB is to write a JNI wrapper for >libusb (maybe using the gnu.io.*-namespace?). > [actually, replying to this and other messages at once, since I'm lagging, as usual] Well, just adding my rant... If I had my way, I'd go with extending existing javax-usb API - like I said before, the guys did a decent job on architecting the top level API. I did thoroughly examine it at the time, and it is a much better match to USB specs than other alternatives. Choosing the 'libusb wrapper' solution now would mean to discard all this hard work that a lot of people have done already. There's nothing wrong with providing a libusb based *implementation*, but the top level API should be left intact, for it is reasonably close to the USB specification. Besides, it is already usable on Linux, despite remarkable lack of activity on the mailing list (at one moment in time the only posts, hundreds of them, were originated by spammers). Paul: hope there's no legal conflict with JSR process someone decides to implement the specs that were put together by the JSR-80 team? >Gerrit. > > --vt From x.frisaye at t4hr.com Tue Jan 31 00:28:09 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 08:28:09 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: Hi all, If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). We are using it for internal projects and we are very satisfied. Is anybody interested? I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. Regards, Xavier -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: lundi 30 janvier 2006 20:24 To: RXTX Developers and Users Subject: Re: [Rxtx] Move .java Files in gnu.io filesystem hierarchy On Mon, 30 Jan 2006, Fabio Frumento wrote: > Hi Trent, > > What do you think about moving the .java files to src/gnu/io folder ? > I'm asking this because i'm using eclipse IDE and it complain about having > the package gnu.io declaration and not having the files in the "correct" > java-style folder hierarchy, what changes are required to the autoconf and > automake configuration files ? > > Moving the files should make easier deal with development tools such as IDE, > ANT and so on... > > if you're thinking about the CVS problem of loosing the files histories SVN > could be an option... I'm using it with lot of projects and i never had a > problem (yes, I've touched wood and iron after last statement...) > Hi Fabio Yes thats overdue. I tried eclipse too and saw the same thing. I've noticed its a standard convention in *.apache and other projects. I think we can do it while preserving CVS history. I will need to ask Ken Thompson to move the directory contenets rather than doing it through CVS. rxtx CVS is off site so we have a backup and I have no shell access there. I've heard good things about SVN. I looked at it. One thing I didnt like while reading a side by side comparison was SVN is not universal on all platforms. [ya but you can....] We do not need extra steps on some of the more obscure platforms which are needing developers something silly. Let me look into it and I'll talk to Ken. src/gnu/io? I think its rather late to be changing the package name. But we could rearrange the src. -- 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 Tue Jan 31 00:46:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:46:20 -0700 (MST) Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org From tdelenik at gmail.com Tue Jan 31 00:49:52 2006 From: tdelenik at gmail.com (Thanasis Delenikas) Date: Tue, 31 Jan 2006 09:49:52 +0200 Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). Message-ID: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Hi all, I have tested the new builds (binaries - v2.1.7) provided by Trent on Win32 & Linux (vmware-emulated RedHat F4) and everything works fine. ( I know this is not the right thing to do, but I cannot build from the latest sources so I've tested the binaries. Have mercy with me... ) As far as my previous Bluetooth via COM error report, I have managed to try it on my Dell laptop with my Nokia 6230i and everything is OK. I have no exceptions. There is probably some other error (specific bluetooth driver maybe(?)) which is affecting RxTx operation. All is well. P.S. Trent, you may add my project (www.jsmsengine.org) on your references' page if you want to. Regards, Thanasis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060131/03522410/attachment-0004.html From f.frumento at ngi.it Tue Jan 31 00:54:50 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 08:54:50 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DE6338.6030406@ngi.it> Message-ID: <43DF17CA.4010808@ngi.it> Hi Trent, kind as usual :) the src is the actual root... i mean we could keep the gnu.io package in the src root folder and specify src as root source folder for the tools... is quite the standard among most java tools, the bin folder will contain the .class and generated binary files (again usually the gnu.io hierarchy is created by the tools when compiling in the bin folder). Best regards Fabio Frumento Trent Jarvi wrote: > On Mon, 30 Jan 2006, Fabio Frumento wrote: > >> Hi Trent, >> >> What do you think about moving the .java files to src/gnu/io folder ? >> I'm asking this because i'm using eclipse IDE and it complain about >> having the package gnu.io declaration and not having the files in the >> "correct" java-style folder hierarchy, what changes are required to >> the autoconf and automake configuration files ? >> >> Moving the files should make easier deal with development tools such >> as IDE, ANT and so on... >> >> if you're thinking about the CVS problem of loosing the files >> histories SVN could be an option... I'm using it with lot of projects >> and i never had a problem (yes, I've touched wood and iron after last >> statement...) >> > > Hi Fabio > > Yes thats overdue. I tried eclipse too and saw the same thing. I've > noticed its a standard convention in *.apache and other projects. > > I think we can do it while preserving CVS history. I will need to ask > Ken Thompson to move the directory contenets rather than doing it > through CVS. rxtx CVS is off site so we have a backup and I have no > shell access there. > > I've heard good things about SVN. I looked at it. One thing I didnt > like while reading a side by side comparison was SVN is not universal on > all platforms. [ya but you can....] We do not need extra steps on some > of the more obscure platforms which are needing developers something silly. > > Let me look into it and I'll talk to Ken. > > src/gnu/io? I think its rather late to be changing the package name. > But we could rearrange the src. > > -- > 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 Tue Jan 31 00:56:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 00:56:23 -0700 (MST) Subject: [Rxtx] New bins for Solaris. Message-ID: I'm going to go through mips, ppc and arm Linux bins tomorrow. But tonight I finished sparc 32 and 64 solaris thanks to a kindly loaned machine. I didn't bother with parallel. I don't think its ever even been tried on Solaris - developer land for sure. sparc32-sun-solaris2.8/librxtxSerial.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), not stripped sparc64-sun-solaris2.8/librxtxSerial.so: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV), not stripped ftp://ftp.qbang.org/pub/rxtx/lastbuild I'll be putting all the bins in a zip file when completed. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 01:02:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 01:02:13 -0700 (MST) Subject: [Rxtx] Test Latest Build + Win32 / Bluetooth via COMxx exception (cannot-reproduce). In-Reply-To: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> References: <310a1a930601302349s63d1d13drb12677736e5a6619@mail.gmail.com> Message-ID: > P.S. > Trent, you may add my project (www.jsmsengine.org) on your references' page > if you want to. Thanks Thanasis. I'll be adding projects to the pages when we really do announce this later in the week. I looked at the transfer logs. There are ~225 downloads a day now. Mostly 2.1-7pre17 and some 2.0-7pre1. I'm sure we will see some bugs when we release but this will clear out my personal mail box for the most part :) -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Tue Jan 31 01:33:37 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Tue, 31 Jan 2006 09:33:37 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) Message-ID: That's right. If we make a maven 2 pom (Project Object Model) for rxtx, every one could build project or generate project file to use in their favourite ide (ie : there is a plugin to generate eclipse project, also for intelliJ,...) simply by installing and using maven 2. In this pom, the project is describred by defining version, dependencies, developpers, mailing lists,... If you're using java lib that are free or if rxtx doesn't use any libraries, normally, it's simple to create the pom. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of Trent Jarvi Sent: mardi 31 janvier 2006 8:46 To: RXTX Developers and Users Subject: RE: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) On Tue, 31 Jan 2006, Xavier Frisaye wrote: > Hi all, > > If you are going to rearrange the src folder, i will propose to use maven 2 and follow its directory structure (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). > Maven 2 simplify java project and give a standard way to make projects (http://maven.apache.org/). > We are using it for internal projects and we are very satisfied. > > Is anybody interested? > > I'm not an expert in maven 2 (yet) but i'm agree to help using it if you choose to make so. > so this would be: rxtx-devel/src/main/java/gnu.io rxtx-devel/src/test/java/ManIwish.java I don't use IDEs very much so I'll let others comment. But I don't see a problem with that. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From f.frumento at ngi.it Tue Jan 31 01:37:38 2006 From: f.frumento at ngi.it (Fabio Frumento) Date: Tue, 31 Jan 2006 09:37:38 +0100 Subject: [Rxtx] Move .java Files in gnu.io filesystem hierarchy - Maven (2) In-Reply-To: References: Message-ID: <43DF21D2.7090200@ngi.it> Hi Xavier, I don't know maven at all but the directory hierarchy listed buy Trent is fine for me... I'll take a look to maven, it seems an interesting project Regards Fabio Frumento Trent Jarvi wrote: > On Tue, 31 Jan 2006, Xavier Frisaye wrote: > >> Hi all, >> >> If you are going to rearrange the src folder, i will propose to use >> maven 2 and follow its directory structure >> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html). >> >> Maven 2 simplify java project and give a standard way to make projects >> (http://maven.apache.org/). >> We are using it for internal projects and we are very satisfied. >> >> Is anybody interested? >> >> I'm not an expert in maven 2 (yet) but i'm agree to help using it if >> you choose to make so. >> > > so this would be: > > rxtx-devel/src/main/java/gnu.io > rxtx-devel/src/test/java/ManIwish.java > > I don't use IDEs very much so I'll let others comment. But I don't see > a problem with that. > > -- > Trent Jarvi > tjarvi at qbang.org > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tpw3316 at ACRretail.com Tue Jan 31 07:52:07 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 31 Jan 2006 09:52:07 -0500 Subject: [Rxtx] Java USB Observations. Message-ID: <89BABD89E119D311BEFD00062905BAE40A8224F7@jaxmail.acr2000.com> For what its worth, it appears that IBM has completed a Windows implementation of javax.usb in support of their UPOS/JavaPos work. Their latest release of UPOS 1.9 for windows includes javax.usb support (in binary form). I would hope it is just a matter of time before they see fit to submit the source back to javax-usb.org. That full UPOS/JavaPos bundle is downloadable at http://www2.clearlake.ibm.com/store/support/html/driverss.html From paul.klissner at sun.com Tue Jan 31 13:33:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:33:00 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: References: <11114696093.20060130184829@domologic.de> <43DEDA00.6090005@sun.com> Message-ID: <43DFC97C.2070701@sun.com> Trent Jarvi wrote: > > Gerrit is on the list so I removed him from the cc. > >> "Lack the low level work?" What does that mean exactly? Do you mean >> experience? > > > Hi Phil > > No. What I was thinking about when I said that was this: > > http://www.steelbrothers.ch/jusb/ > > This is (was?) the start of the big missing component in javax.usb and > jusb. If I read things correctly, the JCP did like I've seen before; > blindside projects like a 600 lb barnie the dinosaur flinging its tail > in a china shop. The 600 lb barnie is easy to get used to. Its the > blindsiding that takes the steam out of projects. No one blindsided jusb. We talked to the jusb project lead and politely and actively asked him to work with us, and join the expert group. We could have negotiated an API that was the best of both worlds. Had jusb been a fully functional API to begin with javax.usb probably wouldn't have been necessary. > > The point isnt that the specification is incorrect. I'm just seeing > lots of pieces not come together. A more inclusive process probably > would have had a very different outcome. > > I'm glad to see libusb is being considered. That looks like a good > option. I was looking at the API this afternoon thinking about giving > it a spin. > > Its all for not without windows though. I think I saw IBM has an > internal project but thats not very interesting from this end. > Thats the low level bits that are missing from what I could see. > > -- > Trent Jarvi > tjarvi at qbang.org From paul.klissner at sun.com Tue Jan 31 13:37:28 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 31 Jan 2006 12:37:28 -0800 Subject: [Rxtx] Java USB Observations. In-Reply-To: <43DF03F0.5030604@freehold.crocodile.org> References: <11114696093.20060130184829@domologic.de> <43DF03F0.5030604@freehold.crocodile.org> Message-ID: <43DFCA88.2020003@sun.com> Vadim Tkachenko wrote: > Gerrit Telkamp wrote: > > [preserved for context] > >> We looked for a javax.usb implementation as well and we came to the >> same result - there is currently no really useful Java-Library for USB >> available. javax-usb.org seems to run on Linux maxhines only, but on >> windows we failed. jusb.sourceforge.net seems to run partial on >> Windows machines, but there is no Linux implementation available. BTW, >> we had no luck when we tried to test jusb.sourceforge.net. >> >> In my opinion the easiest & most promising way to get a >> platform-independent library for USB is to write a JNI wrapper for >> libusb (maybe using the gnu.io.*-namespace?). >> > [actually, replying to this and other messages at once, since I'm > lagging, as usual] > > Well, just adding my rant... > > If I had my way, I'd go with extending existing javax-usb API - like I > said before, the guys did a decent job on architecting the top level > API. I did thoroughly examine it at the time, and it is a much better > match to USB specs than other alternatives. > > Choosing the 'libusb wrapper' solution now would mean to discard all > this hard work that a lot of people have done already. There's nothing > wrong with providing a libusb based *implementation*, but the top level > API should be left intact, for it is reasonably close to the USB > specification. Besides, it is already usable on Linux, despite > remarkable lack of activity on the mailing list (at one moment in time > the only posts, hundreds of them, were originated by spammers). > > Paul: hope there's no legal conflict with JSR process someone decides to > implement the specs that were put together by the JSR-80 team? First of all, I am not a JCP expert, and my statements do not necessarily represent the JCP. For the final word on this, one should consult with the JCP directly. This is what I personally believe: Implementing the specs should not a problem. If you want to be certified as conformant to the spec, or get 100% Pure Java (tm) certification, or something like that, then there might be a few hoops, which I believe the largest part of entails having your implementation pass the TCK (Technology Compatability Kit) tests, which demonstrates that your implementation successfully manifests the API. Paul > >> Gerrit. >> >> > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Tue Jan 31 17:41:04 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 31 Jan 2006 17:41:04 -0700 Subject: [Rxtx] rxtx-2.1-7 Message-ID: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Hi, I have never build the RXTX binaries from the source before but I am using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 years on my project. I was using RXTX-2.1.7pre17 for my project and encountered some of the bugs (especially related to close () and PortInUseExceptions) in the production environment. In our project we are connecting to approx 200 devices (some of them we collect information every 30 seconds) on Serial ports (we use digi boxes). Today when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my COMM SERVER started to crash I tried first copying binaries and Jar file from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but nothing worked. Then I tried to build the binaries from the source files I saw some kernel issues (please see the configure log below). Is this causing the problem? if yes !!! Then what do I need to do to get this working. Thanks in adv. ~pk [root at tocrhtst02 bin]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking java.home /opt/j2sdk1.4.2_03/jre adjusted java.home is /opt/j2sdk1.4.2_03 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.4.2_03 checking os.version 2.4.21-32.0.1.EL WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Sunday, January 29, 2006 11:55 PM To: rxtx at qbang.org Subject: [Rxtx] rxtx-2.1-7 Many thanks to all that have contributed to rxtx-2.1-7! I have managed to test rxtx-2.1-7 on Windows XP and Fedora Linux. A small step. It looks good so far. I won't be releasing the bins tonight. I want to put some documentation in this time to help new users. We will be having rxtx-2.1-8 around May for those that need to get new things in. This includes me. I was terrified tonight when I tried XP. Nothing was working. It turned out vmware didnt have they physical ports attached but windows didn't complain. After digging through that, I'm confident things are OK. For now, developers can preview rxtx-2.1-7 (stable). ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-7.zip (source). I will provide bins probably later this week as I have time. If you want to contribute bins, please let me know. I think this is going to be good for any projects. I just don't want to have to do it twice and cause confusion. When I put bins up, I'll be giving a list of known problems also to save people time. Some of these I will be looking at too. My 'unreleased' last builds are also located at: ftp://ftp.qbang.org/pub/rxtx/lastbuild/ Dmitry's Mac OS X builds are in the source (with an updated .jar). 2.1-7 Jan 29 2006 Mac OS X x86/universal binaries/install fixes Dmitry Markman http://mailman.qbang.org/pipermail/rxtx/20060128/002169.html catch exceptions on flush() so close() works. Adam Walsh http://mailman.qbang.org/pipermail/rxtx/20060118/002131.html more close() performance fixes ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060119/002135.html Blue Tooth Support cleanup writeByte so close works, send the original exceptions so people can see the exception. Paul http://mailman.qbang.org/pipermail/rxtx/20051229/002014.html http://mailman.qbang.org/pipermail/rxtx/20060108/002053.html %s/\`which java\`/\\\`which java\\\`/g in configure.in Takeshi "Ken" Hamasaki http://mailman.qbang.org/pipermail/rxtx/20060105/002039.html System.gc() slows down close() too much. ?yvind Harboe http://mailman.qbang.org/pipermail/rxtx/20060103/002025.html Configure.java message correction User serial_close and serial_open in termios.c JNI_OnLoad and JNI_OnUnload are in SerialImp.c now so remove them from init.c Gerrit Telkamp http://mailman.qbang.org/pipermail/rxtx/20051230/002018.html (See also rxtx-2.1-7pre[1-22]) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 17:58:27 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 17:58:27 -0700 (MST) Subject: [Rxtx] rxtx-2.1-7 In-Reply-To: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03149589@hqexchange3.dot.state.co.us> Message-ID: On Tue, 31 Jan 2006, Kharbanda, Pawan wrote: > Hi, > I have never build the RXTX binaries from the source before but I am > using RXTX API's(downlaoded the binaries from rxtx.org)for almost 2 > years on my project. I was using RXTX-2.1.7pre17 for my project and > encountered some of the bugs (especially related to close () and > PortInUseExceptions) in the production environment. In our project we > are connecting to approx 200 devices (some of them we collect > information every 30 seconds) on Serial ports (we use digi boxes). Today > when I try to do the update to the new RXTX api's (RXTX-2.1.7pre22) my > COMM SERVER started to crash I tried first copying binaries and Jar file > from location ftp://ftp.qbang.org/pub/rxtx/lastbuild/i686-linux/ but > nothing worked. > > Then I tried to build the binaries from the source files I saw some > kernel issues (please see the configure log below). Is this causing the > problem? if yes !!! Then what do I need to do to get this working. > > Thanks in adv. > > ~pk > > [root at tocrhtst02 bin]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > configure: WARNING: Trying libtool. If the following fails install libtool > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... g77 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether g77 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc static flag works... yes > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for g77 option to produce PIC... -fPIC > checking if g77 PIC flag -fPIC works... yes > checking if g77 supports -c -o file.o... yes > checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking dependency style of g++... none > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking sys/fcntl.h usability... yes > checking sys/fcntl.h presence... yes > checking for sys/fcntl.h... yes > checking sys/file.h usability... yes > checking sys/file.h presence... yes > checking for sys/file.h... yes > checking sys/time.h usability... yes > checking sys/time.h presence... yes > checking for sys/time.h... yes > checking sys/signal.h usability... yes > checking sys/signal.h presence... yes > checking for sys/signal.h... yes > checking signal.h usability... yes > checking signal.h presence... yes > checking for signal.h... yes > checking termios.h usability... yes > checking termios.h presence... yes > checking for termios.h... yes > checking grp.h usability... yes > checking grp.h presence... yes > checking for grp.h... yes > checking pwd.h usability... yes > checking pwd.h presence... yes > checking for pwd.h... yes > checking whether gcc needs -traditional... no > checking whether to enable maintainer-specific portions of Makefiles... no > checking java.home /opt/j2sdk1.4.2_03/jre > adjusted java.home is /opt/j2sdk1.4.2_03 > checking os.name Linux > checking os.arch i386 > checking java.vendor Sun Microsystems Inc. > checking java.version 1.4.2_03 > checking os.version 2.4.21-32.0.1.EL > > WARNING: Kernel include files do not match the current kernel <<<<<<<<<<<<<<<<<<<<< IS THIS CAUSING IT TO FAIL > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > > This error is fairly harmless. Usually distro's provide seperate files for this. "kernel-headers" It used to be that kernel includes have a symbolic link made into the user include directory which could lead to problems. Hmm 2.4 kernel? Looks like probably an older enterprise linux system. You will want to compile the library. Just go ahead and type make (and make install or find the library in i686-unknown-linux/.libs). I suspect I used too new of a toolchain for your system while building the linux binaries. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Jan 31 23:15:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 31 Jan 2006 23:15:58 -0700 (MST) Subject: [Rxtx] Bugzilla Message-ID: I'm having a hard time tonight with compilers so I took a break for a few minutes and added a bugzilla for rxtx 2.1 and rxtx 2.0 http://bugzilla.qbang.org/ -- Trent Jarvi tjarvi at qbang.org From illespal at freemail.hu Mon Jan 30 12:46:02 2006 From: illespal at freemail.hu (Illes Pal Zoltan) Date: Mon, 30 Jan 2006 20:46:02 +0100 Subject: [Rxtx] rxtx-2.1-7 - gentoo ebuild In-Reply-To: References: <1138648500.23903.2.camel@localhost> Message-ID: <1138650362.23905.5.camel@localhost> Okay, its working with zip too easily to complain about gzip. I have already posted the ebuild here: http://bugs.gentoo.org/show_bug.cgi?id=120962 Feel free to test it gentoo users. (please :) ) So nevermind the tar.gz, if noone else is in favour of it! Anyway thanks! :) On h, 2006-01-30 at 12:09 -0700, Trent Jarvi wrote: > On Mon, 30 Jan 2006, -- wrote: > > > Hello! > > Could you please provide ftp://jarvi.dsl.frii.com/pub/rxtx/ with a > > tar.gz format for the release. Linux users surely will appreciate. I've > > repackaged for my local tailored gentoo ebuild, and if you make it > > public, I would send it into bugs.gentoo.org for maintainer of rxtx > > ebuild. (Or errr, is this person on this list? :) ) > > > > I thought about this. > > I guess I can. The reason I didn't is you can grab the files fairly > easily: > > jar -tf rxtx-2.1-7.zip > > for instance. That works on all operating systems. If you still need it > for your build system I'll add it. Changing tar -xzvf foo.tar.gz to jar > -xf foo.zip would not be much though and you need java to build. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Ricardo.Letosa at sita.aero Mon Jan 2 05:05:54 2006 From: Ricardo.Letosa at sita.aero (Ricardo.Letosa@sita.aero) Date: Mon, 2 Jan 2006 12:05:54 +0000 Subject: [Rxtx] Ricardo Letosa/Dublin/SITA/WW is out of the office. Message-ID: I will be out of the office starting 30/12/2005 and will not return until 09/01/2006. For urgent issues, please call my mobile +34 651 613 285. Happy New Year. From oyvind.harboe at zylin.com Tue Jan 3 02:52:18 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 10:52:18 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136281938.27620.9.camel@localhost.localdomain> RXTXPort.java invokes the garbage collector. Runtime.getRuntime ().gc (); Why? Does it need to? I generally find it a bit creepy that RXTX interacts with a completely unrelated part of the system. Should my application be invoking the garbage collector, if so, when? There is no way for the client of RXTX to disable the invocation of the garbage collector in RXTX. -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 04:39:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 04:39:56 -0700 (MST) Subject: [Rxtx] garbage collection In-Reply-To: <1136281938.27620.9.camel@localhost.localdomain> References: <1136281938.27620.9.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > RXTXPort.java invokes the garbage collector. > > Runtime.getRuntime ().gc (); > > Why? > > Does it need to? > > I generally find it a bit creepy that RXTX interacts with a completely > unrelated part of the system. > > Should my application be invoking the garbage collector, if so, when? > > There is no way for the client of RXTX to disable the invocation of the > garbage collector in RXTX. > > It should be possible to disable the gc call. The main reason that was there was to ensure that all of the memory is being returned when the port is closed. The focus was on native memory leaks but that helped while obsrving memory use in general while cycling through test code. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 05:15:38 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:15:38 +0100 Subject: [Rxtx] garbage collection Message-ID: <1136290538.27620.18.camel@localhost.localdomain> Garbage collection takes ca. 150ms on my machine. Linux & Debian. This is 50% of the 300ms performance problem w/close() that I'm tracking down. -- ?yvind Harboe http://www.zylin.com From oyvind.harboe at zylin.com Tue Jan 3 05:27:21 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 13:27:21 +0100 Subject: [Rxtx] 300ms performance problems w/close() solved Message-ID: <1136291241.27620.26.camel@localhost.localdomain> I believe I've found the culprit. By removing all invocation of the garbage collector in RXTXPort.java, time to execute close() goes from 300ms to 7ms on my Linux Debian box. Unless there are VERY compelling reasons why RXTX should invoke the garbage collector, I propose to simply remove these invocations: Runtime.getRuntime().gc(); // can easily be > 150ms I would have created a patch for this, but I can't find the CVS server for RXTX. I'm not the only one having trouble: http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html Anyone? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Tue Jan 3 05:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 3 Jan 2006 05:55:57 -0700 (MST) Subject: [Rxtx] 300ms performance problems w/close() solved In-Reply-To: <1136291241.27620.26.camel@localhost.localdomain> References: <1136291241.27620.26.camel@localhost.localdomain> Message-ID: On Tue, 3 Jan 2006, ?yvind Harboe wrote: > I believe I've found the culprit. > > By removing all invocation of the garbage collector in RXTXPort.java, > time to execute close() goes from 300ms to 7ms on my Linux Debian > box. > > Unless there are VERY compelling reasons why RXTX should invoke the > garbage collector, I propose to simply remove these invocations: > > Runtime.getRuntime().gc(); // can easily be > 150ms > > I would have created a patch for this, but I can't find the CVS server > for RXTX. I'm not the only one having trouble: > > http://mailman.qbang.org/pipermail/rxtx/20051228/002005.html > > Anyone? > > It is best to patch against the 2.1 cvs and those changes will get into future 2.0 releases assuming Sun supports that down the road. export CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # mousy is the passwd cvs checkout -r commapi-0-0-1 rxtx-devel I just confirmed that it is working. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Tue Jan 3 07:57:14 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Tue, 03 Jan 2006 15:57:14 +0100 Subject: [Rxtx] close() performance fix Message-ID: <1136300234.27620.35.camel@localhost.localdomain> Improved performance of close(). Shaved off 200ms'ish on a Linux Debian box. ?yvind Harboe Made Runtime.getRuntime().gc() invocations dependant on debug_gc flag. ?yvind Harboe -- ?yvind Harboe http://www.zylin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtxgcfix.txt Type: text/x-patch Size: 2710 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060103/b9c6e820/rxtxgcfix-0005.bin From jvermillard at archean.fr Wed Jan 4 08:28:08 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:28:08 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray Message-ID: <1136388488.3902.3.camel@localhost.localdomain> Hi I got a weirdo exception while trying to write to RS232 port on Linux (2.6.12 + JRE1.5_06 i386). Experimental: JNI_OnLoad called. Devel Library ========================================= Native lib Version = RXTX-2.0-7pre2 Java lib Version = RXTX-2.0-7pre2 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS0 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port found : /dev/ttyS0 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - serial port discovered :/dev/ttyS1 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 port scanned. 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - Listening on port 9001 SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes java.io.IOException: Input/output error in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) I never seen that before with RXTX, any idea ? Julien From jvermillard at archean.fr Wed Jan 4 08:53:36 2006 From: jvermillard at archean.fr (Julien Vermillard) Date: Wed, 04 Jan 2006 16:53:36 +0100 Subject: [Rxtx] java.io.IOException: Input/output error in writeArray In-Reply-To: <1136388488.3902.3.camel@localhost.localdomain> References: <1136388488.3902.3.camel@localhost.localdomain> Message-ID: <1136390016.3902.5.camel@localhost.localdomain> Nevermind I forgot to remove my serial tty console ;) Le mercredi 04 janvier 2006 ? 16:28 +0100, Julien Vermillard a ?crit : > Hi > I got a weirdo exception while trying to write to RS232 port on Linux > (2.6.12 + JRE1.5_06 i386). > > Experimental: JNI_OnLoad called. > Devel Library > ========================================= > Native lib Version = RXTX-2.0-7pre2 > Java lib Version = RXTX-2.0-7pre2 > 2006-01-04 23:15:22,466 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS0 > 2006-01-04 23:15:22,467 [main] INFO SerialPort[/dev/ttyS0:9001] - Port > found : /dev/ttyS0 > 2006-01-04 23:15:22,511 [main] DEBUG SerialPort[/dev/ttyS0:9001] - > serial port discovered :/dev/ttyS1 > 2006-01-04 23:15:22,512 [main] DEBUG SerialPort[/dev/ttyS0:9001] - 2 > port scanned. > 2006-01-04 23:15:22,521 [main] INFO SerialPort[/dev/ttyS0:9001] - > Listening on port 9001 > SerialPort[/dev/ttyS0:9001] - ERROR while writing bytes > java.io.IOException: Input/output error in writeArray > at gnu.io.RXTXPort.writeArray(Native Method) > at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1179) > > I never seen that before with RXTX, any idea ? > > Julien > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tim at raynor.org.uk Wed Jan 4 15:44:40 2006 From: tim at raynor.org.uk (Tim Raynor) Date: Wed, 4 Jan 2006 22:44:40 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? Message-ID: I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have tried the SimpleRead program and I am able to deploy the program successfully but when I try and read from the port I appear to miss some of the data. I have tried varying the flow control settings using setFlowControlMode but no luck. When I try to write data I get "Input/output error in writeArray". I'm guessing this might be due to the same issue but I'm not sure. I've connected a simple terminal emulator to the same port, with the same settings and have verified that data is transmitted and received correctly, so I'm pretty sure the basic comms are set-up OK. Am I doing something daft? Any help greatly appreciated. Thanks, Tim -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 From tjarvi at qbang.org Wed Jan 4 18:25:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 4 Jan 2006 18:25:47 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: References: Message-ID: On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. From tim at raynor.org.uk Thu Jan 5 05:39:39 2006 From: tim at raynor.org.uk (Tim) Date: Thu, 5 Jan 2006 12:39:39 -0000 Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: Message-ID: <200601051241.k05Cf3me026724@www.qbang.org> Hi Trent, Many thanks for your email. I've tracked down the problem which appears to be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I switch to the onboard COM1 it works fine. All the other apps I've tried using with the 8 port board seem to work fine, however when I hit it via rxtx I appear to get data loss. Any ideas as to how I might go about solving this? Thanks again, Tim -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: 05 January 2006 01:26 To: tim at raynor.org.uk; RXTX Developers and Users Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? On Wed, 4 Jan 2006, Tim Raynor wrote: > > I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 > and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have > tried the SimpleRead program and I am able to deploy the program > successfully but when I try and read from the port I appear to miss some of > the data. I have tried varying the flow control settings using > setFlowControlMode but no luck. > > When I try to write data I get "Input/output error in writeArray". I'm > guessing this might be due to the same issue but I'm not sure. > > I've connected a simple terminal emulator to the same port, with the same > settings and have verified that data is transmitted and received correctly, > so I'm pretty sure the basic comms are set-up OK. > > Am I doing something daft? Any help greatly appreciated. > > Thanks, Hi Tim The write error is real but figuring out what is wrong can be another thing :) The native Windows Write is failing. Have you tried the basics? Set you stop bits, parity, timeouts. The buffers don't do anything. You can use buffered io classes from java for that. Try to avoid reading and writing one byte at a time. Make sure you only have one application reading the port. 9600 8 N 1 should work fine. Doing a loop on data available events with single byte reads would be very expensive vs reading with no or a long timeout for small pieces of data. Dont blindly ignore exceptions while setting up the port. They may be telling you something. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006 From tjarvi at qbang.org Thu Jan 5 07:33:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Jan 2006 07:33:18 -0700 (MST) Subject: [Rxtx] Flow control problem with Windows XP SP2? In-Reply-To: <200601051241.k05Cf3me026724@www.qbang.org> References: <200601051241.k05Cf3me026724@www.qbang.org> Message-ID: RXTX should work with COM1-256 but this has only been verified by renaming the ports in windows. I think that the port number should not change anything. Beyond that rxtx just uses the serial interface provided by the kernel. It does not try to output or input bytes to memory locations. Everything is done via the W32 API in termios.c. Multiport cards vary considerably. Some are true UART style multiports. Some are inexpensive serial bit bangers with little/no buffers and minimal event capabilities. Without looking at your code, I would be sure you are not depending upon output buffer empty and data available events if you are unsure about the boards capabilities. It is also possible that the multiport kernel driver has different default settings that vary from the defaults in standard serial ports. Applications may be changing these defaults while rxtx is not unless explicitly told to. So not only may the hardware vary in quality, the drivers can vary in quality too. I'm not aware of which ones are good or bad but I do see considerable variability while looking at linux kernel driver source for various cards. Identifying how the card and driver vary from a standard UART and driver may help identify the problem. Using rxtx as a traditional Java native library has high overhead everytime the JNI (native) code is called when looking at quasi realtime work. This gets worse as you move towards many small reads and writes. I'm not aware of any communication protocol problems with rxtx but one thing to note is rxtx is usually tested for many settings using a loopback connector. This is not unlike connecting a null modem between two ports on your multiport serial card. On Thu, 5 Jan 2006, Tim wrote: > > Hi Trent, > > Many thanks for your email. I've tracked down the problem which appears to > be due to the "Digi AccelePort 8r 920" 8 port serial card I am using. If I > switch to the onboard COM1 it works fine. All the other apps I've tried > using with the 8 port board seem to work fine, however when I hit it via > rxtx I appear to get data loss. Any ideas as to how I might go about solving > this? > > Thanks again, > > Tim > > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: 05 January 2006 01:26 > To: tim at raynor.org.uk; RXTX Developers and Users > Subject: Re: [Rxtx] Flow control problem with Windows XP SP2? > > > On Wed, 4 Jan 2006, Tim Raynor wrote: > >> >> I'm trying to read/write to a serial port (9600 baud) using java 1.5.0_06 >> and rxtx-2.1-7pre17-i386-pc-mingw32 running on Windows XP Pro SP2. I have >> tried the SimpleRead program and I am able to deploy the program >> successfully but when I try and read from the port I appear to miss some > of >> the data. I have tried varying the flow control settings using >> setFlowControlMode but no luck. >> >> When I try to write data I get "Input/output error in writeArray". I'm >> guessing this might be due to the same issue but I'm not sure. >> >> I've connected a simple terminal emulator to the same port, with the same >> settings and have verified that data is transmitted and received > correctly, >> so I'm pretty sure the basic comms are set-up OK. >> >> Am I doing something daft? Any help greatly appreciated. >> >> Thanks, > > Hi Tim > > The write error is real but figuring out what is wrong can be another > thing :) The native Windows Write is failing. > > Have you tried the basics? Set you stop bits, parity, timeouts. The > buffers don't do anything. You can use buffered io classes from java for > that. Try to avoid reading and writing one byte at a time. Make sure you > only have one application reading the port. > > 9600 8 N 1 should work fine. Doing a loop on data available events with > single byte reads would be very expensive vs reading with no or a long > timeout for small pieces of data. > > Dont blindly ignore exceptions while setting up the port. They may be > telling you something. > > From rtc_web at hotmail.com Thu Jan 5 16:14:50 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Thu, 05 Jan 2006 15:14:50 -0800 Subject: [Rxtx] USB question Message-ID: First - I apologize if this is somehow a repeat question. I looked through the archives a bit, but I didn't fine any thing this high-level (I'm pretty new to all this). I'm writing a simple Java application (on Windows) for a client that interfaces with proprietary hardware. Their old hardware used a serial port, and I was able to use RXTX (thanks!) to communicate with their old hardware. Now, the company is creating new hardware (which I don't have in my hands yet) that plugs into a USB port. I'm trying to get more details on the new box, but in general - is it possible to use RXTX to communicate with something connected to the USB port? This will (hopefully) be relatively simple hardware - pulling timestamps/data off at intervals. I thought I read somewhere that it might be possible... I've been looking for other Java/USB connection methods (jUSB and javax.usb), but unfortunately all of them seem to be in very early stages for Windows. Of course, if anyone here has had success with these packages or has other ideas, please let me know! Thanks for your help. -Richard rtc_web at hotmail.com _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dacker at nomadio.net Thu Jan 5 16:33:12 2006 From: dacker at nomadio.net (David S. Acker) Date: Thu, 5 Jan 2006 18:33:12 -0500 Subject: [Rxtx] USB question In-Reply-To: Message-ID: <003c01c61250$65d1a6c0$6802a8c0@wildfire> rxtx-bounces at qbang.org scribbled on : > First - I apologize if this is somehow a repeat question. I > looked through the archives a bit, but I didn't fine any > thing this high-level (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a > client that interfaces with proprietary hardware. Their old > hardware used a serial port, and I was able to use RXTX > (thanks!) to communicate with their old hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more > details on the new box, but in general - is it possible to > use RXTX to communicate with something connected to the USB > port? This will (hopefully) be relatively simple hardware - > pulling timestamps/data off at intervals. > > I thought I read somewhere that it might be possible... I've > been looking for other Java/USB connection methods (jUSB and > javax.usb), but unfortunately all of them seem to be in very > early stages for Windows. Of course, if anyone here has had > success with these packages or has other ideas, please let me know! > Thanks for your help. > > -Richard > rtc_web at hotmail.com > If you have any influence over the hardware, you could use a USB to serial part. That's what my company used when we switched from serial to USB. >From both the embedded side and the PC side it just looks like a serial port. TI has a pretty good part for embedded use that includes Windows device drivers to make it look like a COM port. -Ack From meplists at earthlink.net Thu Jan 5 18:46:44 2006 From: meplists at earthlink.net (Mark Polhamus) Date: Thu, 05 Jan 2006 20:46:44 -0500 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BDCC04.60007@earthlink.net> Richard Colvin wrote: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. My company builds a hardware device, and we just switched from serial to USB. We settled on an USB chip from FTDI. In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual COM Port) driver, and your program will access the virtual port as a serial port using RXTX with no changes except the name of the port might change. So RXTX seems to be working for us using the VCP drivers from FTDI (Linux and Windows). Previously we have used RXTX through VCP drivers with Keyspan USB to serial converters, so it is nothing new. Hopefully your new hardware will support use through a VCP driver and you can continue using RXTX. FYI here are some notes about VCP support from TI and FTDI: Linux support: When I tried to find the Linux VCP driver for the TI chip it was not available from their web site, but they sent me directions after I requested it by email. See http://gate.brimson.com/downloads, files starting with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or greater, for other kernels see http://www.ftdichip.com/Drivers/VCP. Windows support: I believe you have to get and install the driver from the chip maker. I believe both FTDI and TI have the drivers available on their web sites. For TI I think you have to register as a web site user to get access. For FTDI: http://www.ftdichip.com/Drivers/VCP. MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC Drivers are still under development for the below OS versions. Contact usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and 10.3) -- Mark Polhamus From hama at cyberonix.co.jp Thu Jan 5 23:06:15 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:06:15 +0900 Subject: Resolved: [Rxtx] Where can I get the latest rxtx-2.1 on CVS In-Reply-To: Your message of "Wed, 28 Dec 2005 21:15:44 +0900". <051228211544.M1120594@skyplate.cyberonix.co.jp> Message-ID: <060106150615.M0412141@skyplate.cyberonix.co.jp> Hi, there was a mistake by me. I had tried to check the module out without tag name option. I doughtly thought that commapi-0-0-1 is another module and that I don't need it. The description on the download page works. Thanks all, especially Oyvind. In article <051228211544.M1120594 at skyplate.cyberonix.co.jp> hama at cyberonix.co.jp writes: hama>> how can I get the latest CVS version of rxtx-2.1? hama>> hama>> I found the description on the web page: hama>> http://users.frii.com/jarvi/rxtx/cvs.html hama>> hama>> So I logged in, and checked out rxtx-devel. hama>> Then I ran ./configure . hama>> At the end of the process, it requires comm.jar . ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From hama at cyberonix.co.jp Thu Jan 5 23:13:49 2006 From: hama at cyberonix.co.jp (hama@cyberonix.co.jp) Date: Fri, 6 Jan 2006 15:13:49 +0900 Subject: [Rxtx] `which java` should be `dirname \`which java\` ` in configure script Message-ID: <060106151349.M0512141@skyplate.cyberonix.co.jp> Hi, I found some mistake in configure file derived from configure.in . `which java` is used 4 times. They should be `dirname \`which java\` ` because directory name is required for the places. I found them when I ran ./configure on Linux, running on SH4 board. When I run ./configure on i386 machine, the path isn't used. ------------------------------------------------ Takeshi "Ken" Hamasaki : hama at cyberonix.co.jp From halbleib at rechnerbetriebsgruppe.de Thu Jan 5 23:40:08 2006 From: halbleib at rechnerbetriebsgruppe.de (Tom Halbleib) Date: Fri, 06 Jan 2006 07:40:08 +0100 Subject: [Rxtx] USB question In-Reply-To: References: Message-ID: <43BE10C8.10207@rechnerbetriebsgruppe.de> Richard Colvin schrieb: > First - I apologize if this is somehow a repeat question. I looked > through the archives a bit, but I didn't fine any thing this high-level > (I'm pretty new to all this). > > I'm writing a simple Java application (on Windows) for a client that > interfaces with proprietary hardware. Their old hardware used a serial > port, and I was able to use RXTX (thanks!) to communicate with their old > hardware. > > Now, the company is creating new hardware (which I don't have in my > hands yet) that plugs into a USB port. I'm trying to get more details > on the new box, but in general - is it possible to use RXTX to > communicate with something connected to the USB port? This will > (hopefully) be relatively simple hardware - pulling timestamps/data off > at intervals. > > I thought I read somewhere that it might be possible... I've been > looking for other Java/USB connection methods (jUSB and javax.usb), but > unfortunately all of them seem to be in very early stages for Windows. > Of course, if anyone here has had success with these packages or has > other ideas, please let me know! Thanks for your help. > > -Richard > rtc_web at hotmail.com > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx hi Richard, i'm using a Keyspan USB-Addapter (http://www.keyspan.com/products/usb/USA19HS/) with the great RXTX 2.1 - Thanks Trend! After installing the Keyspan drivers a new COM-Port(COM10 eg.) appears in Windows - ready to use. Tom Halbleib ____________________________________________________ Tom Halbleib Rechnerbetriebsgruppe Phone: 0049 / 931 / 99 13 55 62 Fax: 0049 / 931 / 99 13 55 68 e-Mail: halbleib at rechnerbetriebsgruppe.de WWW : www.rechnerbetriebsgruppe.de From oyvind.harboe at zylin.com Fri Jan 6 01:31:55 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Fri, 06 Jan 2006 09:31:55 +0100 Subject: [Rxtx] ping: close() performance fix Message-ID: <1136536315.14772.15.camel@localhost.localdomain> Is there anything more I can do with this close() performance fix patch at this point? Basically it just makes invocation of System.getRuntime().gc() dependent on a debug_gc flag. This reduces the time a close() takes from 300 to 100ms on my Debian Linux box. http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html There are some additional improvements that I've got lined up bringing the time down to ca. 1-7ms, but I'd like to have the garbage collection issue settled & commited before I post further patches. -- ?yvind Harboe http://www.zylin.com From ideiglenes1 at freemail.hu Fri Jan 6 04:13:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Fri, 06 Jan 2006 12:13:41 +0100 Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: <1136546021.7832.3.camel@localhost> Another thing is that I cannot see yet the IOLocked thing in RXTXPort.java which on IOException would zero out IOLocked variable making close of port available again. RXTXPort.java /** * @param b[] * @throws IOException */ public void write (byte b[]) throws IOException { if (debug_write) { z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + b.length + ") " /* + new String(b) */ ); } if (speed == 0) return; if (monThreadisInterrupted == true) { return; } if (fd == 0) throw new IOException (); IOLocked++; waitForTheNativeCodeSilly (); ---> writeArray (b, 0, b.length, monThreadisInterrupted); IOLocked--; if (debug_write) z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + ")"); } ---> would need a try catch(IOException ioex) { IOLocked--; throw ioex; } as discussed before. But I dont see it in CVS yet. I hope it will get into CVS and next release. On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > From robshep at robshepherd.net Fri Jan 6 04:34:04 2006 From: robshep at robshepherd.net (Mr Rob Shepherd) Date: Fri, 6 Jan 2006 11:34:04 +0000 (GMT) Subject: [Rxtx] IOException cannot allocate memory Message-ID: Dear RXTX, I receive this Exception whilst sending data through a gnu.io.SerialPort java.io.IOException: Cannot allocate memory in writeArray The stack trace points to my method where OutputStream.write(byte[]) I've trawled the source, and cannot find where this error may occur but still any help trying to uncover how to defeat this would be greatly appreciated. To make matters worse I am actually using an antique linux driver named bluetty, an host transport layer between usb bluetooth devices and presents a tty interface to linux processes. My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth device. The system has worked flawlessly for many months, but now after a simple change of code to use different commands to the device, I get this error, sometime between 1-6 hours of experimentation.... If I restart the JVM, the error shows up again immediatley. Indicating a problem between rxtx and this linux subsystem. How can I get more debugging information from the rxtx libs? I am quite desperate to see if I can fix this somehow... jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow /dev/ttyUB[012] Customised knoppix gnu/linux, 2.6.7 kernel Many thanks Rob From lyon at docjava.com Fri Jan 6 05:19:16 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 06 Jan 2006 07:19:16 -0500 Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: Hi All, Is there a way to use RXTX over a PS2 line to drive a mouse input on another computer? Thanks! - DL From rtc_web at hotmail.com Fri Jan 6 09:53:27 2006 From: rtc_web at hotmail.com (Richard Colvin) Date: Fri, 06 Jan 2006 08:53:27 -0800 Subject: [Rxtx] USB question In-Reply-To: <43BDCC04.60007@earthlink.net> Message-ID: Thanks for everyone's responses. I was finally able to contact our client's hardware developer, and apparently they are using the FTDI chip (mentioned below). So once I receive the hardware, it sounds like it won't be too difficult. Thanks again! -Richard >From: Mark Polhamus >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] USB question >Date: Thu, 05 Jan 2006 20:46:44 -0500 > >Richard Colvin wrote: > > First - I apologize if this is somehow a repeat question. I looked > > through the archives a bit, but I didn't fine any thing this high-level > > (I'm pretty new to all this). > > > > I'm writing a simple Java application (on Windows) for a client that > > interfaces with proprietary hardware. Their old hardware used a serial > > port, and I was able to use RXTX (thanks!) to communicate with their old > > hardware. > > > > Now, the company is creating new hardware (which I don't have in my > > hands yet) that plugs into a USB port. I'm trying to get more details > > on the new box, but in general - is it possible to use RXTX to > > communicate with something connected to the USB port? This will > > (hopefully) be relatively simple hardware - pulling timestamps/data off > > at intervals. > > > > I thought I read somewhere that it might be possible... I've been > > looking for other Java/USB connection methods (jUSB and javax.usb), but > > unfortunately all of them seem to be in very early stages for Windows. > > Of course, if anyone here has had success with these packages or has > > other ideas, please let me know! Thanks for your help. > >My company builds a hardware device, and we just switched from serial to >USB. > We settled on an USB chip from FTDI. > >In my experience (FTDI and TI) the chip maker will provide a VCP (Virtual >COM >Port) driver, and your program will access the virtual port as a serial >port >using RXTX with no changes except the name of the port might change. So >RXTX >seems to be working for us using the VCP drivers from FTDI (Linux and >Windows). Previously we have used RXTX through VCP drivers with Keyspan >USB >to serial converters, so it is nothing new. > >Hopefully your new hardware will support use through a VCP driver and you >can >continue using RXTX. > >FYI here are some notes about VCP support from TI and FTDI: > >Linux support: When I tried to find the Linux VCP driver for the TI chip it >was not available from their web site, but they sent me directions after I >requested it by email. See http://gate.brimson.com/downloads, files >starting >with "ti_usb"/. The FTDI VCP driver is included in kernel 2.6.9 or >greater, >for other kernels see http://www.ftdichip.com/Drivers/VCP. > >Windows support: I believe you have to get and install the driver from the >chip maker. I believe both FTDI and TI have the drivers available on their >web sites. For TI I think you have to register as a web site user to get >access. For FTDI: http://www.ftdichip.com/Drivers/VCP. > >MAC support: For FTDI see http://www.ftdichip.com/Drivers/VCP, for TI "MAC >Drivers are still under development for the below OS versions. Contact >usb at ti.com for more information". (versions listed are Mac OS 9.2.2 and >10.3) > > >-- Mark Polhamus >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From tjarvi at qbang.org Fri Jan 6 11:41:10 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:41:10 -0700 (MST) Subject: [Rxtx] IOException cannot allocate memory In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Mr Rob Shepherd wrote: > Dear RXTX, > > I receive this Exception whilst sending data through a gnu.io.SerialPort > > java.io.IOException: Cannot allocate memory in writeArray > > The stack trace points to my method where OutputStream.write(byte[]) > > I've trawled the source, and cannot find where this error may occur but still > any help trying to uncover how to defeat this would be greatly appreciated. > > To make matters worse I am actually using an antique linux driver named > bluetty, an host transport layer between usb bluetooth devices and presents a > tty interface to linux processes. > > My java Bluetooth stack uses this, with rxtx to control the usb Bluetooth > device. > > The system has worked flawlessly for many months, but now after a simple > change of code to use different commands to the device, I get this error, > sometime between 1-6 hours of experimentation.... > > If I restart the JVM, the error shows up again immediatley. Indicating a > problem between rxtx and this linux subsystem. > > How can I get more debugging information from the rxtx libs? I am quite > desperate to see if I can fix this somehow... > > jdk1.5, rxtx-rxtx-2.1-7pre17-i686-pc-linux-gnu patched to allow > /dev/ttyUB[012] > > Customised knoppix gnu/linux, 2.6.7 kernel > > > Many thanks > Hi Bob. I'm going to be looking through the exception code this weekend to deal with a previously mentioned close issue. What is going on is the write() in the rxtx SerialImp.c is failing. I'm guessing thats because your blue toothdevice was not there. When rxtx throws an exception from the native code, it tries to ask the api what happened. This can be an error prone way of doing things. (especially with termios.c/win32). But on Linux and Unix like OSs, the error it reports is the last error recorded by the API. Sometimes this is not the error that actually happened. Yes its not ideal. But I'm fairly sure that your failure is happening in SerialImp.c. The function call is WRITE() which is write(). This triggers a goto to fail which is reporting the error. The write is really failing for some reason. Exactly why? I'm not sure. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:47:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:47:06 -0700 (MST) Subject: [Rxtx] jps2 In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, Dr. Douglas Lyon wrote: > Hi All, > Is there a way to use RXTX over a PS2 line to drive > a mouse input on another computer? > Thanks! > - DL What hardware is under rxtx is not important but what is important is that there is a termios layer in the kernel or rxtx (in the w32 case). PS2 does not have this layer. So you would have to create a termios layer or go more along the lines of the Raw class thats just sketched in. It would not be trivial. The PS2 protocol is an error prone pain in the rear. If you like pain, maybe this is for you :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 6 11:52:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 11:52:11 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136546021.7832.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: Yes. I have not committed this yet because I think there is more to this than just the write case. I need to look through the source code and find all cases where this could happen. The fix is not incorrect it just isnt complete and I don't want to do this twice. I will be looking at this during the weekend. My concern isnt the writes, that will get fixed. My concern is all the other calls that lock rxtx and make a native call that can throw exceptions. On Fri, 6 Jan 2006, -- wrote: > Another thing is that I cannot see yet the IOLocked thing in > RXTXPort.java which on IOException would zero out IOLocked variable > making close of port available again. > > RXTXPort.java > > /** > * @param b[] > * @throws IOException > */ > public void write (byte b[]) throws IOException > { > if (debug_write) > { > z.reportln ("Entering RXTXPort:SerialOutputStream:write(" + > b.length + ") " /* + new String(b) */ ); > } > if (speed == 0) > return; > if (monThreadisInterrupted == true) > { > return; > } > if (fd == 0) > throw new IOException (); > IOLocked++; > waitForTheNativeCodeSilly (); > ---> writeArray (b, 0, b.length, monThreadisInterrupted); > IOLocked--; > if (debug_write) > z.reportln ("Leaving RXTXPort:SerialOutputStream:write(" + b.length + > ")"); > } > > > ---> would need a try catch(IOException ioex) { IOLocked--; throw > ioex; } > > as discussed before. But I dont see it in CVS yet. I hope it will get > into CVS and next release. > > > On p, 2006-01-06 at 09:31 +0100, ?yvind Harboe wrote: >> Is there anything more I can do with this close() performance >> fix patch at this point? >> >> Basically it just makes invocation of System.getRuntime().gc() dependent on >> a debug_gc flag. This reduces the time a close() takes from >> 300 to 100ms on my Debian Linux box. >> >> http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html >> >> There are some additional improvements that I've got lined up bringing >> the time down to ca. 1-7ms, but I'd like to have the garbage collection >> issue settled & commited before I post further patches. >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jan 6 12:04:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 12:04:46 -0700 (MST) Subject: [Rxtx] ping: close() performance fix In-Reply-To: <1136536315.14772.15.camel@localhost.localdomain> References: <1136536315.14772.15.camel@localhost.localdomain> Message-ID: Nope. It is going in. Please give me a couple days. I wanted to make sure people had time to mention anything. I also had it in the same mental bit bucket as the write/close mention previously on the list. These are both important and will go in. I guess we are getting close to breaking the tradition of no new releases :) I also have a company that contracted me to do some things I need to touch bases with but the direction we are going is starting to become clearer. This isnt like the early days where you(I) just spin releases when you see something. People actually use rxtx for their own projects and products. Scary at times. But the next release is going to be a stable release with no pre... So we just want to take it slow and give a target. Serial com isnt changing that fast :) On Fri, 6 Jan 2006, ?yvind Harboe wrote: > Is there anything more I can do with this close() performance > fix patch at this point? > > Basically it just makes invocation of System.getRuntime().gc() dependent on > a debug_gc flag. This reduces the time a close() takes from > 300 to 100ms on my Debian Linux box. > > http://mailman.qbang.org/pipermail/rxtx/20060103/002028.html > > There are some additional improvements that I've got lined up bringing > the time down to ca. 1-7ms, but I'd like to have the garbage collection > issue settled & commited before I post further patches. > > From sam_godfrey at uk2.net Fri Jan 6 18:01:30 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 01:01:30 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601070105.k0715aFe012142@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Fri Jan 6 18:13:07 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Jan 2006 18:13:07 -0700 (MST) Subject: [Rxtx] SerialEvent not working. In-Reply-To: <200601070105.k0715aFe012142@www.qbang.org> References: <200601070105.k0715aFe012142@www.qbang.org> Message-ID: On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import that > instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can send > using RXTX and it is received by the device which sends a response, it's > just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org From sam_godfrey at uk2.net Sat Jan 7 07:10:33 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Sat, 7 Jan 2006 14:10:33 -0000 Subject: [Rxtx] SerialEvent not working. In-Reply-To: Message-ID: <200601071414.k07EEeSQ016715@www.qbang.org> Cheers Trent for the reply. Well as a quick overview, one of the functions of my program is to poll a device to see if it is online and has any information. If it is online with no info, it replies a one byte packet, if it is online with information, it replies with the info packet that can be any length, and of course if it is offline there is no reply. The response doesn't always arrive after a set time period (it is a very old device) and so I use a serial event to trigger an event when data is received at the serial port. If nothing is received after 'x' time period, it is assumed offline. The class 'implements SerialPortEventListener' and uses the method below to process events: public void serialEvent(SerialPortEvent event) { System.out.println("HERE"); //Line put in only to test if event is triggered at all. It isn't switch (event.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: . . . . The connection to the serial port is slow: 600bps 8N1 With this set and nothing else (no rts, etc): serialPort.notifyOnDataAvailable(true); Cheers, Sam. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: 07 January 2006 01:13 To: RXTX Developers and Users Subject: Re: [Rxtx] SerialEvent not working. On Sat, 7 Jan 2006, Sam Godfrey wrote: > rxtx-2.1-7pre17 is all installed correctly (I believe) The install is a work of 'something' :) > but I cannot get the > 'public void serialEvent(SerialPortEvent event) {....' to do anything. > > The code I am using is fine with javax.comm, and as soon as I import > that instead of the RXTX gnu.io the serialEvent works fine again. > > To make matters a little stranger, everything else works fine - I can > send using RXTX and it is received by the device which sends a > response, it's just using the 'serialEvent trigger' to receive that doesn't work. > > Any ideas anyone? :) I suspect you are trying to do something (at least I) never anticipated. You want to send an event from your application? Could you paste a sniglet? I suspect this is easy to fix when there is a working demo of the problem. I always pictured the events comming from something in the native code. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From ideiglenes1 at freemail.hu Sun Jan 8 06:52:41 2006 From: ideiglenes1 at freemail.hu (--) Date: Sun, 08 Jan 2006 14:52:41 +0100 Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> Message-ID: <1136728361.18967.3.camel@localhost> Hello! RXTXCommDriver.java line 503: String[] Temp = { "comx", // linux COMMX synchronous serial card "holter", // custom card for heart monitoring "modem", // linux symbolic link to modem. ----> "rfcomm", // bluetooth serial device "ttyircomm", // linux IrCommdevices (IrDA serial emu) Please care to add this "rfcomm" line, commit and include into the new release, as this serial device name is not yet included in current CVS! Thank you, Paul From sam_godfrey at uk2.net Thu Jan 5 07:57:53 2006 From: sam_godfrey at uk2.net (Sam Godfrey) Date: Thu, 5 Jan 2006 14:57:53 -0000 Subject: [Rxtx] SerialEvent not working. Message-ID: <200601051501.k05F1uI6027497@www.qbang.org> rxtx-2.1-7pre17 is all installed correctly (I believe) but I cannot get the 'public void serialEvent(SerialPortEvent event) {....' to do anything. The code I am using is fine with javax.comm, and as soon as I import that instead of the RXTX gnu.io the serialEvent works fine again. To make matters a little stranger, everything else works fine - I can send using RXTX and it is received by the device which sends a response, it's just using the 'serialEvent trigger' to receive that doesn't work. Any ideas anyone? :) From tjarvi at qbang.org Sun Jan 8 10:25:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 8 Jan 2006 10:25:49 -0700 (MST) Subject: [Rxtx] new device name added to Linux-all-ports In-Reply-To: <1136728361.18967.3.camel@localhost> References: <1136536315.14772.15.camel@localhost.localdomain> <1136546021.7832.3.camel@localhost> <1136728361.18967.3.camel@localhost> Message-ID: On Sun, 8 Jan 2006, -- wrote: > Hello! > > RXTXCommDriver.java > line 503: > > String[] Temp = { > "comx", // linux COMMX synchronous serial card > "holter", // custom card for heart monitoring > "modem", // linux symbolic link to modem. > ----> "rfcomm", // bluetooth serial device > "ttyircomm", // linux IrCommdevices (IrDA serial emu) > > Please care to add this "rfcomm" line, commit and include into the new > release, as this serial device name is not yet included in current CVS! > > Thank you, > Paul > Hi Paul. That makes sense. I'll put it in. There is a larger issue with all those devices. There are too many. I've never found a good way of dealing with them. There are two extremes. One is a full home workstation that can enumerate all ports in a reasonable time. The other is an embeded system that cant. The devices we do expose are the minimum. Bluetooth should be in there. People buying multiport cards end up learning about this file and making the changes. There are probably 40 devices. If I remember correctly rxtx enumerates twice for some reason I never figured out making the problem twice as bad. I thought udev would make this less of a problem. And maybe it can. But I don't really trust that interface. If you have any experience with the kernel interfaces at that level, they are all never ending changes with no real direction. Thats great as the kernel improves but makes a difficult target for software. -- Trent Jarvi tjarvi at qbang.org From oyvind.harboe at zylin.com Wed Jan 11 06:44:42 2006 From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe) Date: Wed, 11 Jan 2006 14:44:42 +0100 Subject: [Rxtx] more close() performance fixes Message-ID: <1136987082.8042.28.camel@localhost.localdomain> I've got another performance fix for close() lined up. I typically see close() taking ms instead of 100's of ms. Do I wait until the previous performance fix is committed instead of submitting a new patch with multiple changes? -- ?yvind Harboe http://www.zylin.com From tjarvi at qbang.org Wed Jan 11 11:33:46 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 11:33:46 -0700 (MST) Subject: [Rxtx] more close() performance fixes In-Reply-To: <1136987082.8042.28.camel@localhost.localdomain> References: <1136987082.8042.28.camel@localhost.localdomain> Message-ID: On Wed, 11 Jan 2006, ?yvind Harboe wrote: > I've got another performance fix for close() lined up. I typically see > close() taking ms instead of 100's of ms. > > Do I wait until the previous performance fix is committed instead of > submitting a new patch with multiple changes? > > I'll start committing everything in ~5 hours. I was trying to contact some folks before going forward and thats mostly done. You can also have CVS access for write it you like. Or post your changes here. Thats best for people looking in the future to see the changes/issue. From tjarvi at qbang.org Wed Jan 11 15:45:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 11 Jan 2006 15:45:41 -0700 (MST) Subject: [Rxtx] Moving on. Message-ID: So Sun broke commapi. I think thats clear. If anyone here has ever dealt with companies, You know it takes a while. I've replied to all companies that expressed interest in good faith. I think its safe to say at this point rxtx is going to follow the collective memory. That does not involve Sun. It also means many of the patches that have showed up here have been very influential. I for one am no longer agreeing to the Sun EULA. That does not mean I will be trying to break CommAPI. In fact I'll be trying very hard to preserve that. But things are about to move on. -- Trent Jarvi tjarvi at qbang.org From d.tonhofer at m-plify.com Thu Jan 12 06:14:25 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Thu, 12 Jan 2006 14:14:25 +0100 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi wrote: > So Sun broke commapi. I think thats clear. If anyone here has ever > dealt with companies, You know it takes a while. > > I've replied to all companies that expressed interest in good faith. > > I think its safe to say at this point rxtx is going to follow the > collective memory. That does not involve Sun. It also means many of > the patches that have showed up here have been very influential. > > I for one am no longer agreeing to the Sun EULA. That does not mean > I will be trying to break CommAPI. In fact I'll be trying very hard to > preserve that. But things are about to move on. > > -- > Trent Jarvi > tjarvi at qbang.org Hi Trent, This is a somewhat cryptic and despondent announcement. I suppose you are you referring to the Java Communication API 3.0 Update 1: . I haven't had a chance to take a look at any changes or anything (didn't even know there was a new API) so your announcement comes a bit as a surprise. So basically this means one has to search & replace javax.comm by gnu.io? So be it. Don't sweat it. Best regards, -- David Tonhofer P.S. I just now see on rxtx.org: "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, removed it and replaced it with an API version 3.0 rxtx can not support for almost all platforms rxtx supports, the rxtx 2.0 release has been hidden and rxtx 2.1 which replaces the API in package gnu.io is being offered to avoid confusion. The rxtx 2.0 support will resume if the design issues are resolved by Sun." Also: From paul.klissner at sun.com Thu Jan 12 08:41:22 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 07:41:22 -0800 Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: <43C678A2.70805@sun.com> I'd like to ask what the main issues are, and at the same time present a little background about javax.comm and it's current disposition within Sun. I've been working with javax.comm on and off for a few years. I initially did some work with it for a little while in 2000, about three years after it's inception in 1997. The reason I got involved with javax.comm and that I am currently the de facto owner is, the group I'm in makes the Sun Ray thin client and needs javax.comm to be able to access Sun Ray serial ports in addition to server side ports, based on unique selection criteria. It isn't a high profile endeavor by the company a this time. I see from the mailing list strong words about how Sun 'broke' javax.comm and did 'hostile' coding in 3.0. I'm not sure where that assessment comes from, so rather than leap to any conclusions, can someone explain to me how RxTx is using javax.comm, and exactly what isn't working in 3.0? I'd like to know what the expectations are and where they came from. I can say in all sincerity, there is no plot to subvert the API or to disenfranchise anyone. If anything, it is really more an issue of time and resources -- the perennial dilemma. For what it's worth, I have some issues with the API also, and some constraints, as well. I've been keeping note of my own issues with the API, and waiting until there are some people from outside of Sun willing to collaborate, make a commitment and provide some energy to help evolve javax.comm into a more mature adaptive interface that fully addresses the needs of the community. Thanks, Paul David Tonhofer, m-plify S.A. wrote: > --On Wednesday, January 11, 2006 3:45 PM -0700 Trent Jarvi > wrote: > >> So Sun broke commapi. I think thats clear. If anyone here has ever >> dealt with companies, You know it takes a while. >> >> I've replied to all companies that expressed interest in good faith. >> >> I think its safe to say at this point rxtx is going to follow the >> collective memory. That does not involve Sun. It also means many of >> the patches that have showed up here have been very influential. >> >> I for one am no longer agreeing to the Sun EULA. That does not mean >> I will be trying to break CommAPI. In fact I'll be trying very hard to >> preserve that. But things are about to move on. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > > > > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > > I suppose you are you referring to the Java Communication API 3.0 > Update 1: . > > I haven't had a chance to take a look at any changes or anything > (didn't even know there was a new API) so your announcement comes > a bit as a surprise. > > So basically this means one has to search & replace javax.comm by > gnu.io? > > So be it. Don't sweat it. > > Best regards, > > -- David Tonhofer > > > P.S. > > I just now see on rxtx.org: > > "Sun Dec 18 2005: After Sun Javax.comm broke their flexible 2.0 API, > removed it and replaced it with an API version 3.0 rxtx can not > support for almost all platforms rxtx supports, the rxtx 2.0 release > has been hidden and rxtx 2.1 which replaces the API in package gnu.io > is being offered to avoid confusion. The rxtx 2.0 support will resume > if the design issues are resolved by Sun." > > Also: > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jan 12 11:58:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 11:58:57 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: References: Message-ID: > Hi Trent, > > This is a somewhat cryptic and despondent announcement. > Yes it was. There is even a name for it in Internet backchannels; 'tajlish.' But we are all here now. I'm not on the phone. I'm not talking to several companies all going different directions. I appologize but at the same time, rxtx and CommAPI are going to move forward in a relationship we have not seen in 8 years. So here you go. I've moved everything here. speak your minds. I'll be going the conservative route as usual. I'll be posting a list of technical issues rxtx has with CommAPI in its current form. I'm a maintainer. Thats not the same boat as developers. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 12 13:45:59 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 13:45:59 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI Message-ID: The current problems with CommAPI 3.0 are fairly simple. Dont hard code native libraries into the CommAPI layer. What does rxtx do? Well its a termios layer. This is POSIX and when I first looked at commapi, POSIX appeared to be a logical solution. That ment creating a termios.c in rxtx. I saw sun was having problems building a w32 package or lost interest. This is probably what most are interested in but its just a note in the back of my head. Some would suggest maybe Microsoft has a termios in its NT Posix package. But it really does not. What does rxtx deliver? With a termios layer, rxtx gives multiple platforms usability. Really all platforms if you tinker with the builds enough. What could Sun offer? Right now, Sun is breaking rxtx in multiple ways. Years ago there was an informal relationship between rxtx and Sun. Kevin Hester worked with Sun and created what is rxtx 2.0 more or less. This was a layer Sun could use. So rxtx was the buggy drivers :) on everything Sun didnt do. With the recent release it appears to me that Sun hard coded loading native libraries. RXTX always just worked with the Solaris packages (even on w32). I didnt see much in the Windows offering. So this is really ugly from our end. There isnt any documentation about exactly what those native calls do. Its a black box. Replacing the libraries looks questionable at best. As an example.. how is this supposed to work on ARM linux? Does it really make sense for me or others to reverse engineer what has been done? What direction do we go? Well. I'm open minded. I think it is obvious there are some folks doing more developement than I am now. Both at Sun and in the community at large. Maybe in a previous time I'd just look at this and run forward. But right now, I'd just like to get folks together. -- Trent Jarvi tjarvi at qbang.org From dwagenknecht at gmail.com Thu Jan 12 14:34:47 2006 From: dwagenknecht at gmail.com (Dominik Wagenknecht) Date: Thu, 12 Jan 2006 22:34:47 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: Well I'm only a happy user of rxtx under Windows and Linux, and for me it's always been kind of hard to find out "what it's doing"... If it really gets down to reverse engineer all the inner bindings Sun has implemented I strongly suggest NOT DOING so. The single most beautiful way of doing a native library IMHO is the way the SWT team (eclipse.org) is doing. Concept: o A ultra-thin native layer that maps low-level functions 1:1 to Java o A JAR-file per platform that implements the interfaces There is good reason to do so: Basically, everything is Java. In SWT every proficient Windows API developer can do/fix whatever he wants the way he did in Visual C but without the hassle of a second developing environment. As only basic function mappingss are in the JNI layer, changes rarely happen. Once the relevant POSIX functions are patched through to Java everyone can happily hack around in Java with all the nice commodities like JavaDoc... As rxtx is for Java developers I think it's easier to find people able to program Java than C! But one big pitfall: Performance. Every JNI-call takes a considerable amount of time. So eventually some logic will have to be implemented in C (especially because rxtx is time-critical). On the other hand: When compiling with gcj for restrained systems this becomes a non-issue. With a small DLL I would be happy to help and test especially under Windows -- I don't know POSIX, but I know the relevant Windows-API fairly well. Just some long-term thoughts Dominik Am 12.01.2006 um 21:45 schrieb Trent Jarvi: > > The current problems with CommAPI 3.0 are fairly simple. Dont hard > code native libraries into the CommAPI layer. > > What does rxtx do? > > Well its a termios layer. This is POSIX and when I first looked at > commapi, POSIX appeared to be a logical solution. That ment > creating a termios.c in rxtx. I saw sun was having problems > building a w32 package or lost interest. This is probably what > most are interested in but its just a note in the back of my head. > > Some would suggest maybe Microsoft has a termios in its NT Posix > package. But it really does not. > > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. > Really all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there > was an informal relationship between rxtx and Sun. Kevin Hester > worked with Sun and created what is rxtx 2.0 more or less. This > was a layer Sun could use. So rxtx was the buggy drivers :) on > everything Sun didnt do. > > With the recent release it appears to me that Sun hard coded > loading native libraries. RXTX always just worked with the Solaris > packages (even on w32). I didnt see much in the Windows offering. > So this is really ugly from our end. There isnt any documentation > about exactly what those native calls do. Its a black box. > Replacing the libraries looks questionable at best. As an > example.. how is this supposed to work on ARM linux? Does it > really make sense for me or others to reverse engineer what has > been done? > > What direction do we go? > > Well. I'm open minded. I think it is obvious there are some folks > doing more developement than I am now. Both at Sun and in the > community at large. Maybe in a previous time I'd just look at this > and run forward. But right now, I'd just like to get folks together. > > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pbarthelemy at aim.com Thu Jan 12 15:43:00 2006 From: pbarthelemy at aim.com (Philippe Barthelemy) Date: Thu, 12 Jan 2006 23:43:00 +0100 Subject: [Rxtx] low-level setting question Message-ID: Hi I used PortMon to sniff the serial communication between my PC and a device. I then compared the intercepted data between a working C program and a attempt at a rxtx port. How can I match the C program serial setting using rxtx ? the C program sets the port as this : 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 80000040 XonLimit:2048 XoffLimit:512 16 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR and rxtx one as this 10 22:52:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 2048 OutSize: 1024 76 22:52:33 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE WordLength: 8 77 22:52:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0 78 22:52:33 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace: 0 XonLimit:0 XoffLimit:0 79 22:52:33 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 80 22:52:33 IRP_MJ_WRITE Serial0 SUCCESS Length 7: 34 A6 55 55 56 B8 25 81 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: TXEMPTY 82 22:52:33 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: 96 22:52:34 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR ( I removed quite a lot of lines.... ) I played with the settings of a RXTXport, but I never matched the C conf, and I never get the comm to work in Java... TIA, --Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060112/b1a94bbf/attachment-0005.html From tjarvi at qbang.org Thu Jan 12 17:34:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Thu Jan 12 19:32:53 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 18:32:53 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: Message-ID: <43C71155.1070403@sun.com> Trent Jarvi wrote: > What does rxtx deliver? > > With a termios layer, rxtx gives multiple platforms usability. Really > all platforms if you tinker with the builds enough. > > What could Sun offer? > > Right now, Sun is breaking rxtx in multiple ways. Years ago there was > an informal relationship between rxtx and Sun. Kevin Hester worked with > Sun and created what is rxtx 2.0 more or less. Who did Kevin work with in Sun, and what agreement or contract did they make? Thanks, Paul From tjarvi at qbang.org Thu Jan 12 19:55:34 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 19:55:34 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C71155.1070403@sun.com> References: <43C71155.1070403@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> What does rxtx deliver? >> >> With a termios layer, rxtx gives multiple platforms usability. Really all >> platforms if you tinker with the builds enough. >> >> What could Sun offer? >> >> Right now, Sun is breaking rxtx in multiple ways. Years ago there was an >> informal relationship between rxtx and Sun. Kevin Hester worked with Sun >> and created what is rxtx 2.0 more or less. > > Who did Kevin work with in Sun, and what agreement or contract did they > make? > Hi Paul Kevin did that as a neat hack. He did several interesting hacks including a signal library. http://freshmeat.net/projects/javasignals/ I'm not aware of any formal agreement between Kevin and Sun. But if you look at the javax.comm.properties documentation in CommAPI 2.0, you can see there was an informal relationship that currently does not work. I think I described that correctly but you can contact Kevin for more details. His current email is on the link provided. Perhaps you are reading more into 'worked with Sun' when I'm just saying he cooperated. Before that rxtx was a much more simple library doing .. rx and tx :) RXTX and Sun CommAPI have always been sortof doing their own things. There has not been any significant communication between the projects that I know of. I don't know If Kevin suggested the current layout or if Sun decided to do it and then Kevin went with it. "May 19, 1998 The Java Comm for Linux project has implemented initial CommAPI compatibility. For further information contact Kevin Hester. This is work in progress. See the download page for the latest major changes or the CVS page for the most current code." http://www.rxtx.org/indexold.html This work then known as JCL or Java Comm For Linux was later merged with rxtx. It is now one remaining class. RXTXCommDriver.java:| Copyright 1998 Kevin Hester I hope that helps. -- Trent Jarvi tjarvi at qbang.org From Saul.Finkelstein at sbcglobal.net Wed Jan 11 19:03:13 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Wed, 11 Jan 2006 18:03:13 -0800 Subject: [Rxtx] ping! (subscription test) Message-ID: <43C5B8E1.9090701@sbcglobal.net> Hi all, Just testing to see if I'm subscribed yet. Saul From Saul.Finkelstein at sbcglobal.net Thu Jan 12 17:15:11 2006 From: Saul.Finkelstein at sbcglobal.net (Saul Finkelstein) Date: Thu, 12 Jan 2006 16:15:11 -0800 Subject: [Rxtx] Hello to the list Message-ID: <43C6F10F.7060003@sbcglobal.net> Hi all, Just saying "Hi!" to see if my subscription works. (I've been having some e-mail issues subscribing to the list). Saul From tjarvi at qbang.org Thu Jan 12 23:42:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 12 Jan 2006 23:42:42 -0700 (MST) Subject: [Rxtx] Moving on. In-Reply-To: <43C678A2.70805@sun.com> References: <43C678A2.70805@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > I'd like to ask what the main issues are, and at the same time > present a little background about javax.comm and it's current > disposition within Sun. > > I've been working with javax.comm on and off for a few years. > I initially did some work with it for a little while in 2000, > about three years after it's inception in 1997. The reason I > got involved with javax.comm and that I am currently the > de facto owner is, the group I'm in makes the Sun Ray thin > client and needs javax.comm to be able to access Sun Ray > serial ports in addition to server side ports, based on unique > selection criteria. It isn't a high profile endeavor by the > company a this time. > Welcome to the list Paul. I have enjoyed your work and CommAPI and I hope we can improve it for everyone. > I see from the mailing list strong words about how Sun 'broke' > javax.comm and did 'hostile' coding in 3.0. I'm not sure > where that assessment comes from, so rather than leap to any > conclusions, can someone explain to me how RxTx is using > javax.comm, and exactly what isn't working in 3.0? I'd like to > know what the expectations are and where they came from. I can > say in all sincerity, there is no plot to subvert the API or to > disenfranchise anyone. If anything, it is really more an issue > of time and resources -- the perennial dilemma. What I got excited about was some of the implementation details which break RXTX's ability to provide drivers under CommAPI using the javax.comm.properties. What I'm seeing and maybe you can correct me here is we lost a great deal of flexability while bringing some nice new features. As an example. I'm looking at the Unix class. This has a couple native functions. No big deal. But the Unix class is hard coded to load the Sun native libraries. This means the library will only work on the specific platforms Sun compiles native libraries for. Or RXTX has to name its native libraries the same as Sun and stub or implement the native functions. I think this would be a bad thing for everyone. We can no longer take the Solaris or Linux ports, override the low level libraries and have the previously flexible design work on WinCE, Embeded Linux on ppc, arm, bsd, maybe 64 bit windows... Many of the neat things hobby folks like to do with libraries like RXTX. In fact, from what I can tell, RXTX can not help the current CommAPI implementation in any meaningful way because of these recent changes. >From what I can tell, rxtx is going to have to go with version 2.1 which means jumping out of the javax.comm namespace so we can get our toys working. > > For what it's worth, I have some issues with the API also, and > some constraints, as well. I've been keeping note of my own > issues with the API, and waiting until there are some people > from outside of Sun willing to collaborate, make a commitment > and provide some energy to help evolve javax.comm into a more > mature adaptive interface that fully addresses the needs of the > community. > We could work together to improve the API and widen acceptance. I don't dislike commapi at all. It has been a great learning experience for me to follow the work from Sun's engineers. I realize we are all short on time, resources, .. These things happen. In the past, the CommAPI design was flexible enough that people could take the RXTX driver for win32 and run it with the Solaris offering from Sun. This made many of the hobby folks here very happy as they could do things like use CommAPI on cell phones with blue tooth. It would be best for both projects if we could get back to the way things worked before. It was great for both projects. I don't see how I can help at this point though. -- Trent Jarvi tjarvi at qbang.org From jsmsengine at gmail.com Fri Jan 13 00:15:01 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 09:15:01 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/ee1aac50/attachment-0005.html From paul.klissner at sun.com Fri Jan 13 00:18:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Thu, 12 Jan 2006 23:18:44 -0800 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> Message-ID: <43C75454.5040504@sun.com> Trent Jarvi wrote: > Hi Paul > > I'm not aware of any formal agreement between Kevin and Sun. But if you > look at the javax.comm.properties documentation in CommAPI 2.0, you can > see there was an informal relationship that currently does not work. I > think I described that correctly but you can contact Kevin for more > details. His current email is on the link provided. > > Perhaps you are reading more into 'worked with Sun' when I'm just saying > he cooperated. Before that rxtx was a much more simple library doing .. > rx and tx :) RXTX and Sun CommAPI have always been sortof doing their > own things. There has not been any significant communication between > the projects that I know of. I looked over the references you provided done some research and have concluded that Jagane Sundar, the original javax.comm developer in Sun, upon receiving support requests from the community, responded by making what appears to be an ad hoc SPI interface that wasn't formalized or documented well, thus constraining Sun's implementation considerably. Since then, the advent of thin clients and hotpluggable USB dongles are examples that illustrate the lack of flexibility of that architecture, wherein a provider plugin model would probably be more appropriate. In retrospect, I think there is some legitimacy to your claim that we broke an implicit stability contract with the 3.0 release, without realizing it. I was unaware of the secret handshake of the founding forefathers, nor RxTx's dependency on the implementation's peculiarities. Because there are bugfixes in 3.0, and because I'd rather not confuse customers with too many versions of the API floating around, I think the best approach in the near term is for me to come up with "javax.comm 3.0, Update 2", which insulates the native driver from Sun's recent implementation changes, and I have an approach in mind. I plan to release javax.comm 3.0, Update 2 by mid-February, which will give me time to finish up other urgent business at hand, and throw the 'release candidate' bits over the fence to the RxTx community in advance to be sure the problems are cleared up prior to release. Hope that resolves things to everyone's satisfaction for the time being. Paul From tjarvi at qbang.org Fri Jan 13 00:34:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:34:35 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> References: <4f8cec620601122315i202c051fyad93ba3505e01f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Goodday to all of you. > > Since this is my first post to the list, let me introduce myself a bit: > > I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API > package which can be used to send and/or receive SMS messages through a GSM > modem/phone. > Since my project has begun, I have relied on SUN's COMM API for my serial > communication needs. Win32 support was fine, Linux so so. But from SUN COMM > v3.0, I faced serious trouble... Win32 support is gone and I have never > managed to install it on Linux. Anyway, you know the story better than me. > > So, I switched to RXTX. Linux support is great, but I cannot make it work on > Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM > v2.0 for Win32 platforms. > > Enough with me... Welcome to the list Thanasis > > The problem: > > I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. Those binaries should be good. Well, they have gone through formal tests on a loopback device. Things can be missed. > > My installation is as follows: > 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver > 2) RXTXComm.jar goes to "lib/ext" directory. > 3) rxtxserial.dll goes to "bin". > Same changes applied to both JDK and JRE installation dir. > Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" > throws exceptions), tested baud speeds 9600 & 19200. > Thats all good. But you don't need a javax.comm.properties file with rxtx 2.1. Rxtx _should_ respect the properties file but its a stub in the code. > The compile is fine. At runtime, ** I never get any response from the serial > port **. > The same scenario works fine on Linux (ok, no .dll here, just the .so file) > The same scenario works fine on Win32 when I switch my code to SUN COMMAPI > v2.0 > > Any ideas? What am I doing wrong? > Bare with me if this has been brought up before, but I am new to the list > (and to RXTX project). I suspect you are keeping the 2.0 and 2.1 libraries on the same machine. This is a common issue. As an extreme test, nuke your java install from orbit and install rxtx 2.1. The 'zoo.' Usually when I see reports like this someone has Sun CommAPI and rxtx 2.1 installed switching back and forth. Also try running your application from a DOS shell. You may see something informative there. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jan 13 00:46:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 00:46:14 -0700 (MST) Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: <43C75454.5040504@sun.com> References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: On Thu, 12 Jan 2006, Paul Klissner wrote: > Trent Jarvi wrote: >> Hi Paul >> >> I'm not aware of any formal agreement between Kevin and Sun. But if you >> look at the javax.comm.properties documentation in CommAPI 2.0, you can see >> there was an informal relationship that currently does not work. I think I >> described that correctly but you can contact Kevin for more details. His >> current email is on the link provided. >> >> Perhaps you are reading more into 'worked with Sun' when I'm just saying he >> cooperated. Before that rxtx was a much more simple library doing .. rx >> and tx :) RXTX and Sun CommAPI have always been sortof doing their own >> things. There has not been any significant communication between the >> projects that I know of. > > I looked over the references you provided done some research and have > concluded that Jagane Sundar, the original javax.comm developer in Sun, > upon receiving support requests from the community, responded by making > what appears to be an ad hoc SPI interface that wasn't formalized or > documented well, thus constraining Sun's implementation considerably. > Since then, the advent of thin clients and hotpluggable USB dongles are > examples that illustrate the lack of flexibility of that architecture, > wherein a provider plugin model would probably be more appropriate. > > In retrospect, I think there is some legitimacy to your claim that > we broke an implicit stability contract with the 3.0 release, > without realizing it. I was unaware of the secret handshake of the > founding forefathers, nor RxTx's dependency on the implementation's > peculiarities. > > Because there are bugfixes in 3.0, and because I'd rather not confuse > customers with too many versions of the API floating around, I think > the best approach in the near term is for me to come up with > "javax.comm 3.0, Update 2", which insulates the native driver from > Sun's recent implementation changes, and I have an approach in mind. > > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. > Hi Paul I look forward to working with you from this end. There is going to be a major rxtx release in May. So I think we can do some good on both sides. Maybe we can get back to coding now. Thank you. -- Trent Jarvi tjarvi at qbang.org From x.frisaye at t4hr.com Fri Jan 13 02:17:47 2006 From: x.frisaye at t4hr.com (Xavier Frisaye) Date: Fri, 13 Jan 2006 10:17:47 +0100 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: Hi all, We using rxtx in our application to send/receive sms (thus this is similar to jSMSEngine) and we're encountering one problem on windows 2000 server or XP based system. Our application is installed as a NT Service using JavaService.exe and when the server reboots, the application is listening for ever to the port. But if we restart the service, the application works. Sometimes, it also happens while the application is running for a long time. When using Sun's Comm api 2.0 for Win32 the first problem seems to be solved (We haven't test the second problem with Sun's Comm and thus i can't affirm it doesn't occurs in this case). I think our problems are very similar to yours but we don't have found any solutions yet. Regards, Xavier Frisaye -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org]On Behalf Of jSMSEngine Admin Sent: vendredi 13 janvier 2006 8:15 To: RTXT Mailing List Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Goodday to all of you. Since this is my first post to the list, let me introduce myself a bit: I am Thanasis Delenikas, developer of jSMSEngine. jSMSEngine is a Java API package which can be used to send and/or receive SMS messages through a GSM modem/phone. Since my project has begun, I have relied on SUN's COMM API for my serial communication needs. Win32 support was fine, Linux so so. But from SUN COMM v3.0, I faced serious trouble... Win32 support is gone and I have never managed to install it on Linux. Anyway, you know the story better than me. So, I switched to RXTX. Linux support is great, but I cannot make it work on Windows. My plan is to switch to RXTX completely and to avoid using SUN COMM v2.0 for Win32 platforms. Enough with me... The problem: I am using 20/02/2005 CVS snapshot RXTX v2.1 binaries. My installation is as follows: 1) javax.comm.properties -> Driver=gnu.io.RXTXCommDriver 2) RXTXComm.jar goes to "lib/ext" directory. 3) rxtxserial.dll goes to "bin". Same changes applied to both JDK and JRE installation dir. Of course, I "import gnu.io.*". I am connecting to "COM1" device ("com1" throws exceptions), tested baud speeds 9600 & 19200. The compile is fine. At runtime, ** I never get any response from the serial port **. The same scenario works fine on Linux (ok, no .dll here, just the .so file) The same scenario works fine on Win32 when I switch my code to SUN COMMAPI v2.0 Any ideas? What am I doing wrong? Bare with me if this has been brought up before, but I am new to the list (and to RXTX project). Thank you, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/d18786b4/attachment-0005.html From jsmsengine at gmail.com Fri Jan 13 02:17:20 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Fri, 13 Jan 2006 11:17:20 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems Message-ID: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Thanks for the welcome and the info, Trent. I have removed every trace of old code from my Java dirs: property files, win32com.dll, jars, etc that have to do with COMMAPIs and started from the beginning... But, no luck. The only info I see is: << Devel Library ========================================= Native lib Version = RXTX-2.1-7pre20 Java lib Version = RXTX-2.1-7pre20 >> I don't know if there is any switch or something to enable and get extra debugging info from your libraries(?) If you need any other specific info, please let me know. Do I need any extra components (any gnu win32 libraries or anything) to make RXTX work on Win32? -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060113/20c55b02/attachment-0005.html From tjarvi at qbang.org Fri Jan 13 04:25:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 04:25:31 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems In-Reply-To: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> References: <4f8cec620601130117j414d335aq3d5c8e007947bf0f@mail.gmail.com> Message-ID: On Fri, 13 Jan 2006, jSMSEngine Admin wrote: > Thanks for the welcome and the info, Trent. > > I have removed every trace of old code from my Java dirs: property files, > win32com.dll, jars, etc that have to do with COMMAPIs and started from the > beginning... > > But, no luck. > The only info I see is: > > << > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre20 > Java lib Version = RXTX-2.1-7pre20 >>> > > I don't know if there is any switch or something to enable and get extra > debugging info from your libraries(?) If you need any other specific info, > please let me know. > > Do I need any extra components (any gnu win32 libraries or anything) to make > RXTX work on Win32? Hi Thanasis RXTX should be OK after you get that message. The install is correct. There are no required libraries other than the dll you installed and I see loaded. I guess I'm not understanding the bug. Nothing happens? -- Trent Jarvi tjarvi at qbang.org From tma at mail.island.net Fri Jan 13 14:02:30 2006 From: tma at mail.island.net (Tom Alldread) Date: Fri, 13 Jan 2006 13:02:30 -0800 Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <200601130821.k0D8LsSH007233@www.qbang.org> References: <200601130821.k0D8LsSH007233@www.qbang.org> Message-ID: <43C81566.3070805@mail.island.net> Greetings Folks: I am wondering if anyone here knows if Sun has any intention of providing CommApi 3 support for Windows platforms in the future? Seems like a huge arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed something with my several attempts to find Windows comm support within Sun's JAVA web site. I apologize if this is a little out of context but I just don't know where else there is for a hobbyist to ask this question. Very Best Regards, Tom Alldread -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 2006-01-11 From pbarthelemy at aim.com Fri Jan 13 14:09:26 2006 From: pbarthelemy at aim.com (pbarthelemy@aim.com) Date: Fri, 13 Jan 2006 16:09:26 -0500 Subject: [Rxtx] low-level setting question In-Reply-To: References: Message-ID: <8C7E69CC4CE9B34-A04-17599@mblk-d37.sysops.aol.com> Hi, For what I gather, the C app uses the following settings: I'll give a look on how to match those using the rxtx.org parameters. --P t.c_cflag = B9600 | CS8 | CLOCAL | CREAD; t.c_cflag |= CSTOPB; t.c_iflag = IGNPAR; t.c_oflag = 0; t.c_lflag = 0; t.c_cc[VTIME] = 0; t.c_cc[VMIN] = 0; tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&t); -----Original Message----- From: Trent Jarvi To: RXTX Developers and Users Sent: Thu, 12 Jan 2006 17:34:30 -0700 (MST) Subject: Re: [Rxtx] low-level setting question On Thu, 12 Jan 2006, Philippe Barthelemy wrote: > Hi > > I used PortMon to sniff the serial communication between my PC and a device. > > I then compared the intercepted data between a working C program and a > attempt at a rxtx port. > > How can I match the C program serial setting using rxtx ? > > the C program sets the port as this : > > 1 22:44:33 IOCTL_SERIAL_SET_QUEUE_SIZE Serial0 SUCCESS InSize: 1048 > OutSize: 128 10 22:44:33 IOCTL_SERIAL_SET_BAUD_RATE Serial0 > SUCCESS Rate: 9600 11 22:44:33 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS > 12 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 13 22:44:33 > IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: ERROR Parity: NONE > WordLength: 8 14 22:44:33 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 > ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 15 22:44:33 IOCTL_SERIAL_SET_HANDFLOW > Serial0 SUCCESS Shake:1 Replace:80000040 XonLimit:2048 XoffLimit:512 16 > 22:44:33 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 17 22:44:33 > IOCTL_SERIAL_SET_RTS Serial0 SUCCESS 19 22:44:33 > IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:0 RM:0 RC:10 WM:0 WC:0 20 > 22:44:34 IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: RXCLEAR 21 22:44:34 > IOCTL_SERIAL_PURGE Serial0 SUCCESS Purge: TXCLEAR > and rxtx one as this > Hi Philippe I can see a couple differences but I'm not sure how you are getting this. Is this windows? There is a hidden function in SerialImp.c called dump_termios. That will dump the entire termios struct in your c app and or rxtx. I would start with that function and see how the termios struct differs. Thats basicially what your are doing above. But the termios struct is what controls all of that. If this is windows, there could be problems in the termios layer. I dont know how obscure your application is but with that information you can set the entire termios structure to what you need. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. From tjarvi at qbang.org Fri Jan 13 14:47:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 13 Jan 2006 14:47:26 -0700 (MST) Subject: [Rxtx] Sun CommApi 3 - Future Support for Windows? In-Reply-To: <43C81566.3070805@mail.island.net> References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: On Fri, 13 Jan 2006, Tom Alldread wrote: > Greetings Folks: > > I am wondering if anyone here knows if Sun has any intention of providing > CommApi 3 support for Windows platforms in the future? Seems like a huge > arena for Sun to leave void of JAVA comm support. Makes me wonder if I missed > something with my several attempts to find Windows comm support within Sun's > JAVA web site. > > I apologize if this is a little out of context but I just don't know where > else there is for a hobbyist to ask this question. > Hi Tom Speaking for rxtx, we will be supporting windows in the next release Sun makes of CommAPI 3.0. That is the plan over hear. We have discussed current problems with 3.0 and it appears that those issues will be addressed. I hope Sun also make a windows release giving users more options. You would have to communicate with Sun to know what their plans are. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jan 14 04:27:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 06:27:33 -0500 Subject: [Rxtx] singleton design pattern In-Reply-To: References: <200601130821.k0D8LsSH007233@www.qbang.org> <43C81566.3070805@mail.island.net> Message-ID: Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug From daniel.manzke at technik-emden.de Sat Jan 14 05:26:22 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 13:26:22 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton a good choice... didn't no if it possible... but I you want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } --> because if a thread want to get the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not intialized... he calls isloaded() creates the rxtxcommdriver and intialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 06:08:00 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:08:00 -0700 (MST) Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: On Sat, 14 Jan 2006, Daniel Manzke wrote: > Hi, > > I think the idea of a singleton a good choice... didn't no if it possible... > but I you want to obtain a little fix at the loading point... because if you > use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > --> because if a thread want to get the driver and it isn't initialized yet > ... driver == null ... and now because he is a thread... it could happen > that he have to stop and another thread starts and tries to get the > driver... but it isn't not intialized... he calls isloaded() creates the > rxtxcommdriver and intialized it... than he stops... and the other thread > starts the same game... and now you have two instance... could give some > problems?! > This looks great to me. I had noticed Doug's observation before just in debug logs. Cleaning that up would make enumberation much less of an overhead. Does this look good to you Doug? -- Trent Jarvi tjarvi at qbang.org (starting cvs commits today) From lyon at docjava.com Sat Jan 14 06:09:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 14 Jan 2006 08:09:12 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: Quite right! To be thread safe, the getInstance should be synchronized. Also, in order to beam the native libs into the jdk/jre/lib/i386 directories, the user will need to have write permission to the directory. How do you prompt the user for a root password so that the installation can proceed? For example: public static void checkDriver() { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) badCommDriver(); else System.out.println("driver OK!"); } private static void badCommDriver() { if (!In.getBoolean("Could not load RXTX driver. \n" + "Do you want me to install it?")) return; fixDriver(); checkDriver(); } private static void fixDriver() { installDriver((String) In.multiPrompt(SystemUtils.getLibraryPaths(), "select a path for install", "path selector dialog")); } private static void installDriver(String path) { if (path == null) System.exit(0); File f = new File(path); if (!f.canWrite()) { In.message("you can't write to:" + path); fixDriver(); } In.message("you have selected:"+f.getAbsolutePath()); In.message("not implemented yet"); System.exit(0); } As you can see, if we can't write to the directory where the native methods go, it is a bit of a show stopper. Under windows, we would need Administrator passwords to do the install. Under Unix or Mac, we might need the root pwd. But even with these PWDS, I don't know how to override the lack of write permission to the directory. Macs have an http://www.amug.org/~glguerin/sw/authkit/overview.html Authorization toolkit. But what about others? Is there another way to do the native lib install? Thanks! - Doug >Hi, > >I think the idea of a singleton a good choice... didn't no if it possible... >but I you want to obtain a little fix at the loading point... because if you >use threads it could be that the singleton would be loaded twice... > > public static CommDriver getInstance() { > --> if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > >--> because if a thread want to get the driver and it isn't initialized yet >... driver == null ... and now because he is a thread... it could happen >that he have to stop and another thread starts and tries to get the >driver... but it isn't not intialized... he calls isloaded() creates the >rxtxcommdriver and intialized it... than he stops... and the other thread >starts the same game... and now you have two instance... could give some >problems?! > > >-----Urspr?ngliche Nachricht----- >Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von >Dr. Douglas Lyon >Gesendet: Samstag, 14. Januar 2006 12:28 >An: RXTX Developers and Users; lyon at docjava.com >Betreff: [Rxtx] singleton design pattern > >Hi All, >I see initialize being called more than once in static blocks >contained by the RXTXCommDriver. > >However, it is my understanding that initialize should not >be called more than once. > >More importantly, we need a run-time means to determine >if a driver can be loaded. > >Would it be better design to make use of the Singleton Design Pattern >to obtain an instance of the RXTXCommDriver? > >Something like: > >public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public static CommDriver getInstance() { > if (driver != null) return driver; > if (isLoaded()) { > driver = new RXTXCommDriver(); > driver.initialize(); > return driver; > } > return null; > } > > private static boolean isLoaded() { > if (!NativeLibDetect.isLibInPath("rxtxSerial")) > return false; > System.loadLibrary("rxtxSerial"); > return true; > } > > public static void main(String[] args) { > System.out.println("SafeCommDriver"); > CommDriver cd = getInstance(); > if (cd == null) > System.out.println("program terminates; could not load >RXTX driver"); > else System.out.println("driver OK!"); > } >} >Adding the SafeCommDriver to the CommDriver access should do no harm, >and it would >give a central point for checking the existence of the native library >in the load path before throwing an exception. It also makes sure >that initialize is invoked only once. Finally, if the >library is missing, we could offer to install it...at run time, from >a web page. This might make the serial port software more robust. > > - Doug >_______________________________________________ >Rxtx mailing list >Rxtx 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 jsmsengine at gmail.com Sat Jan 14 06:19:46 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 15:19:46 +0200 Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. Message-ID: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Hi Trent. I have written a small Java program to better show you what is going on. Maybe you are in a better position to trace it in your dev environment. The program opens the port, send an "AT\r" command and expects something to read - the "OK\r" response. This small app should work with GSM phones, modems, ISDN terminal adapters - anything that accepts basic AT commands. I use a GSM phone. When I run it with RxTx, it never gets a response. If I switch to SUN (import javax.comm.*, bla bla) I get the "OK\r" back... *********************** import java.io.*; import gnu.io.*; public class TestRxTx { public void doit() throws Exception { CommPortIdentifier portId; SerialPort serialPort; InputStream inStream; OutputStream outStream; String response; portId = CommPortIdentifier.getPortIdentifier("COM1"); serialPort = (SerialPort) portId.open("TestRxTx", 2000); inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.enableReceiveTimeout(5000); outStream.write('A'); outStream.write('T'); outStream.write('\r'); outStream.flush(); while (inStream.available() == 0) { System.out.println("Still waiting for response..."); Thread.sleep(500); } response = ""; while (inStream.available() > 0) response = response + (char) inStream.read(); System.out.println(response); } public static void main(String[] args) { TestRxTx app = new TestRxTx(); try { app.doit(); } catch (Exception e) { e.printStackTrace(); } } } *********************** P.S. I forgot to mention earlier, but my system is WinXP - I don't know if it has anything to do... Best Regards, -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/0c22408b/attachment-0005.html From tjarvi at qbang.org Sat Jan 14 06:27:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 06:27:33 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: References: Message-ID: On Fri, 13 Jan 2006, Xavier Frisaye wrote: > Hi all, > > We using rxtx in our application to send/receive sms (thus this is > similar to jSMSEngine) and we're encountering one problem on windows > 2000 server or XP based system. Our application is installed as a NT > Service using JavaService.exe and when the server reboots, the > application is listening for ever to the port. But if we restart the > service, the application works. Sometimes, it also happens while the > application is running for a long time. When using Sun's Comm api 2.0 > for Win32 the first problem seems to be solved (We haven't test the > second problem with Sun's Comm and thus i can't affirm it doesn't occurs > in this case). I think our problems are very similar to yours but we > don't have found any solutions yet. > > Regards, > > Xavier Frisaye > Hi Xavier listening for ever... Have you tried changing the default timeout? I suspect Sun and RXTX just have different defaults (never timeout in the RXTX case). -- Trent Jarvi tjarvi at qbang.org From daniel.manzke at technik-emden.de Sat Jan 14 06:30:47 2006 From: daniel.manzke at technik-emden.de (Daniel Manzke) Date: Sat, 14 Jan 2006 14:30:47 +0100 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: Message-ID: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Hi, I think the idea of a singleton would be a good choice... didn't know if it's possible... but I want to obtain a little fix at the loading point... because if you use threads it could be that the singleton would be loaded twice... public static CommDriver getInstance() { --> if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } because if a thread want to get a object of the driver and it isn't initialized yet ... driver == null ... and now because he is a thread... it could happen that he have to stop and another thread starts and tries to get the driver... but it isn't not initialized... he calls isloaded() creates the rxtxcommdriver and initialized it... than he stops... and the other thread starts the same game... and now you have two instance... could give some problems?! Fix... do it synchronized... it s slower but safe... Sorry for my bad English... long time ago I need it ;D Daniel -----Urspr?ngliche Nachricht----- Von: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] Im Auftrag von Dr. Douglas Lyon Gesendet: Samstag, 14. Januar 2006 12:28 An: RXTX Developers and Users; lyon at docjava.com Betreff: [Rxtx] singleton design pattern Hi All, I see initialize being called more than once in static blocks contained by the RXTXCommDriver. However, it is my understanding that initialize should not be called more than once. More importantly, we need a run-time means to determine if a driver can be loaded. Would it be better design to make use of the Singleton Design Pattern to obtain an instance of the RXTXCommDriver? Something like: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public static CommDriver getInstance() { if (driver != null) return driver; if (isLoaded()) { driver = new RXTXCommDriver(); driver.initialize(); return driver; } return null; } private static boolean isLoaded() { if (!NativeLibDetect.isLibInPath("rxtxSerial")) return false; System.loadLibrary("rxtxSerial"); return true; } public static void main(String[] args) { System.out.println("SafeCommDriver"); CommDriver cd = getInstance(); if (cd == null) System.out.println("program terminates; could not load RXTX driver"); else System.out.println("driver OK!"); } } Adding the SafeCommDriver to the CommDriver access should do no harm, and it would give a central point for checking the existence of the native library in the load path before throwing an exception. It also makes sure that initialize is invoked only once. Finally, if the library is missing, we could offer to install it...at run time, from a web page. This might make the serial port software more robust. - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jan 14 08:37:58 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) Subject: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. In-Reply-To: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> References: <4f8cec620601140519y37845801r6d11a58b6e2365fb@mail.gmail.com> Message-ID: On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > outStream.write('A'); outStream.write('T'); outStream.write('\r'); I wont have the XP system up for a while. But I'm curious. I'm sure this has worked in the past but it was just done a little differently. outStream.write( new String("at").getBytes() ); outStream.write( byte 0x0D ); // \r Carriage Return outStream.write( byte 0x0A ); // \n Line Feed The reason this has worked before is we have a contributed example with the source contrib/SNComHandler.java. This was done on linux, but the writes should be working the same on w32. Perhaps there is a bug with write( int b ) going to w32. Does the above work? We can backtrace from the w32 write to see what its sending and why if there is a difference. But maybe the line feed is part of what is missing. From tjarvi at qbang.org Sat Jan 14 09:23:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 09:23:05 -0700 (MST) Subject: AW: [Rxtx] Unix Authentification In-Reply-To: References: <200601141223.k0ECN3qJ015865@farad.et-inf.fho-emden.de> Message-ID: > As you can see, if we can't write to the directory where the native > methods go, it is a bit of a show stopper. Under windows, we > would need Administrator passwords to do the install. Under Unix > or Mac, we might need the root pwd. But even with these PWDS, > I don't know how to override the lack of write permission to the > directory. On Solaris, Linux, FreeBSD and Mac OSX I know that for password authentification, you need to 'PAM-ify' the library. That would mean linking in the PAM libraries. I've not seen how this is done, but CUPs should be an example program that does it. http://www.kernel.org/pub/linux/libs/pam/ This may even be in Java already as Solaris uses PAM. -- Trent Jarvi tjarvi at qbang.org From shauvikr at yahoo.com Sat Jan 14 09:50:34 2006 From: shauvikr at yahoo.com (Shauvik Roy Choudhary) Date: Sat, 14 Jan 2006 16:50:34 +0000 (GMT) Subject: [Rxtx] Xmodem Help needed... Message-ID: <20060114165035.9485.qmail@web52704.mail.yahoo.com> Hi, I tried implementing the Xmodem protocol to send a file to a microcontroller. But however, it does not seem to work properly... any ideas?? Actually, i'm trying to program an Atmel AVR microcontroller from the terminal.. the code works all fine when i send the file from hyper terminal... but my code doesn't work :) Thanx in Advance... Xmodem reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/hyperterminal_xmodem_file_transfer.asp My Code: public String XmodemSend(String File1) throws IOException{ Filename=File1; FileInputStream fstream; DataInputStream in; try { fstream = new FileInputStream(Filename); in = new DataInputStream(fstream); } catch(Exception e) { System.err.println("File input error"); return "File Not Loaded"; } int j,k,chksum; while (in.available() !=0) { //System.out.println("\nPacket no :"+packetno); data[0]=SOH; data[1]= packetno; data[2]= (0xFF-packetno); for(k=3;k<=130;k++){ if(in.available()!=0){ data[k]=in.readByte(); //System.out.println((count++)+" : "+in.readByte()); } else data[k]= EOF; } chksum=0; for(j=0;j<=130;j++){ chksum+=data[j]; } data[k] = (chksum & 65280)/256; data[k+1]= chksum-(chksum & 65280); //for(j=0;j<=132;j++) System.out.print(data[j]+","); for(j=0;j<=132;j++) out.write(data[j]); out.flush(); packetno++; } in.close(); return "File Loaded Successfully"; } Regards, Shauvik Roy Choudhary. Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/f6d15a9c/attachment-0005.html From d.tonhofer at m-plify.com Sat Jan 14 10:50:30 2006 From: d.tonhofer at m-plify.com (David Tonhofer, m-plify S.A.) Date: Sat, 14 Jan 2006 18:50:30 +0100 Subject: [Rxtx] Primary Problems with CommAPI In-Reply-To: References: <43C71155.1070403@sun.com> <43C75454.5040504@sun.com> Message-ID: <7CE835874ACF56FDDB34CD01@[192.168.1.7]> Sun's Paul Klissner wrote (January 12, 2006 11:18 PM -0800): > I plan to release javax.comm 3.0, Update 2 by mid-February, which will > give me time to finish up other urgent business at hand, and throw the > 'release candidate' bits over the fence to the RxTx community in > advance to be sure the problems are cleared up prior to release. > Hope that resolves things to everyone's satisfaction for the time > being. Upon which Trent Jarvi responds (January 13, 2006 12:46 AM -0700): > I look forward to working with you from this end. There is going to > be a major rxtx release in May. So I think we can do some good on both > sides. > > Maybe we can get back to coding now. > > Thank you. .... Rock and Roll, guys!!! From jsmsengine at gmail.com Sat Jan 14 13:02:18 2006 From: jsmsengine at gmail.com (jSMSEngine Admin) Date: Sat, 14 Jan 2006 22:02:18 +0200 Subject: [Rxtx] Re: Win32 problems. Message-ID: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Hi. No, the code with the bytes does not work either... :( On Linux, both mine (original) and your code (modified) work fine. Message: 6 > Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) > From: Trent Jarvi > Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. > To: RXTX Developers and Users > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > > > outStream.write('A'); outStream.write('T'); outStream.write('\r'); > > I wont have the XP system up for a while. But I'm curious. I'm sure this > has worked in the past but it was just done a little differently. > > outStream.write( new String("at").getBytes() ); > outStream.write( byte 0x0D ); // \r Carriage Return > outStream.write( byte 0x0A ); // \n Line Feed > > The reason this has worked before is we have a contributed example with > the source contrib/SNComHandler.java. This was done on linux, but the > writes should be working the same on w32. > > Perhaps there is a bug with write( int b ) going to w32. Does the above > work? We can backtrace from the w32 write to see what its sending and why > if there is a difference. But maybe the line feed is part of what is > missing. -- Thanasis Delenikas http://www.jsmsengine.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060114/2adafe7a/attachment-0005.html From tjarvi at qbang.org Sat Jan 14 13:48:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 14 Jan 2006 13:48:56 -0700 (MST) Subject: [Rxtx] Re: Win32 problems. In-Reply-To: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> References: <4f8cec620601141202s766e5397y90bc82be0e3b3539@mail.gmail.com> Message-ID: I cant see whats wrong right off. The code is going to write( int b ) in RXTXPort.java. This calls writeByte() in SerialImp.c. Then the WRITE() calls serial_write() in termios.c. So the code isnt that hard to follow if you want to take a look. If you have some ideas you want to try or debugging messages put it, I can give you a working buildtree on qbang so you don't have to go through the mess of setting that up. Which version of rxtx 2.1 did you try on windows? pre17 was tested a great deal on windows but not with a modem. the snapshot was less tested. I may have to put together a machine with a modem.. On Sat, 14 Jan 2006, jSMSEngine Admin wrote: > Hi. > > No, the code with the bytes does not work either... :( > > On Linux, both mine (original) and your code (modified) work fine. > > > > > Message: 6 >> Date: Sat, 14 Jan 2006 08:37:58 -0700 (MST) >> From: Trent Jarvi >> Subject: Re: [Rxtx] RXTX 20/01/2005 version on Win32 Problems. >> To: RXTX Developers and Users >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Sat, 14 Jan 2006, jSMSEngine Admin wrote: >> >>> outStream.write('A'); outStream.write('T'); outStream.write('\r'); >> >> I wont have the XP system up for a while. But I'm curious. I'm sure this >> has worked in the past but it was just done a little differently. >> >> outStream.write( new String("at").getBytes() ); >> outStream.write( byte 0x0D ); // \r Carriage Return >> outStream.write( byte 0x0A ); // \n Line Feed >> >> The reason this has worked before is we have a contributed example with >> the source contrib/SNComHandler.java. This was done on linux, but the >> writes should be working the same on w32. >> >> Perhaps there is a bug with write( int b ) going to w32. Does the above >> work? We can backtrace from the w32 write to see what its sending and why >> if there is a difference. But maybe the line feed is part of what is >> missing. > > > > > -- > Thanasis Delenikas > http://www.jsmsengine.org > From lyon at docjava.com Sun Jan 15 07:47:34 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 15 Jan 2006 09:47:34 -0500 Subject: AW: [Rxtx] singleton design pattern In-Reply-To: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> References: <200601141327.k0EDRRab018771@farad.et-inf.fho-emden.de> Message-ID: Hi All, I have been using Java Web Start and RXTX to load native methods when needed. What is the procedure for doing this with regular Java applications? Below is what I do for Web Start....it would be great if this could be used by regular apps.... - DL